From: hopper (Mark Hofmann) 

Sent: Wednesday, March 01, 1995 12:23 AM 

To: Tim B. Robinson' 

Subject: Re: csyn 

Tim B. Robinson writes: 
Is fred back yet? I have some unexpected csyn output and I was 
wondering if he had installed his latest version before going away. 
The main thing I'm worried about is it seems to be complaining about 
the xbmux2 cells having e qualifiers on the selects. I seem to 
remember we decided in the reviews something had to change there, but 
appears we may have a disconnect. 

Fred will be back next Monday, 6 Mar. 

I have some Csyn results which I ran last Monday in Fred's directory; 

~/chip.bsrc/euterpe/verilog/bsrc/tbr_euterpe-pass 1 .csyn 

this file is about 1.3Meg (I believe yours result was bigger?) and is based 
on some code/csyn tables which which is probably still testing and has not 
released. I have not had a chance to look at these results. Maybe we could 
go over them together sometime today? Or you could point me to the 
suspicious results in the file... 

-thanks, 
hopper 
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From: Potatoe Chip [chip@rhea] 

Sent: Wednesday, March 01 , 1 995 2:42 AM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/hc BOM 90.0 initiated by hopper completed @ Wed Mar 1 
00:40:53 PST 1995 with exit status 0.. chip 

lock read: File exists 
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From: hopper (Mark Hofmann) 

Sent: Wednesday, March 01 , 1995 3:06 AM 

To: Tim B. Robinson' 

Subject: Re: csyn 

Tim B. Robinson writes: 

Which euterpe BOM were you off? Mine is 240.0 and I havd about 7MB. 
There was some real stuff which rich has fixed. I'm mostly concerned 
about the 2 input mux problem. 

Also 240.0 

-hopper 
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From: hopper (Mark Hofmann) 

Sent: Wednesday, March 01 , 1995 9:45 AM 

To: 'B. P. Wong' 

Cc: 'bpw (B. P. Wong)'; 'tbr (Tim B. Robinson)'; 'fwo (Fred Obermeier)' 
Subject: Re: tlb csyn 

B. P. Wong writes: 

> Don't panic. Mark ran it using a local set of csyn rules fred was 

> working on but has nt released yet, and the problem is gone. 

> We need to be sure as soon as fred is back, but I think my run was a 

> false alarm. 
> 

>Tim 

> 

Thanks, 
bpw 

Hi bp, 

If you're interested the results from the BOM 240.0 testcase that I ran 
can be found in 

-fwo/chip.bsrc/euterpe/verilog/bsrc/tbr_euterpe-pass 1 .csyn 


-hopper 
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From: 


tbr 


Sent: 


Subject: 


To: 


Wednesday, March 01, 1995 10:58 AM 
'hopper (Mark Hofmann)' 
Re: csyn 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Wed Mar I): 

Tim B. Robinson writes: 
Is fred back yet? I have some unexpected csyn output and I was 
wondering if he had installed his latest version before going away. 
The main thing I'm worried about is it seems to be complaining about 
the xbmux2 cells having e qualifiers on the selects. I seem to 
remember we decided in the reviews something had to change there, but 
appears we may have a disconnect. 

Fred will be back next Monday, 6 Mar. 

I have some Csyn results which I ran last Monday in Fred's directory: 

-/chip . bsrc/ euterpe/ ver ilog/bsrc/tbr_euterpe-pas s 1 . csyn 

this file is about 1.3Meg (I believe yours result was bigger?) and is based 
on some code/csyn tables which which is probably still testing and has not 
released. I have not had a chance to look at these results. Maybe we could 
go over them together sometime today? Or you could point me to the 
suspicious results in the file... 

Which euterpe BOM were you off? Mine is 240.0 and I havd about 7MB. 
There was some real stuff which rich has fixed. I'm mostly concerned 
about the 2 input mux problem. 


Tim 
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From: 


tbr 


Sent: 


Subject: 


To: 


Wednesday, March 01, 1995 11:20 AM 
'hopper (Mark Hofmann)' 
Re: csyn 


Follow Up Flag: Follow up 
Flag Status: Red 


Mark Hofrnann wrote (on Wed Mar 1): 

Tim B. Robinson writes: 
Is fred back yet? I have some unexpected csyn output and I was 
wondering if he had installed his latest version before going away. 
The main thing I'm worried about is it seems to be complaining about 
the xbmux2 cells having e qualifiers on the selects. I seem to 
remember we decided in the reviews something had to change there, but 
appears we may have a disconnect. 

Fred will be back next Monday, 6 Mar. 

I have some Csyn results which I ran last Monday in Fred's directory: 

~/ch ip . bsrc/euterpe/ ver i log/bsrc/tbr_euterpe-pass 1 .csyn 

this file is about 1 .3Meg (I believe yours result was bigger?) and is based 
on some code/csyn tables which which is probably still testing and has not 
released. I have not had a chance to look at these results. Maybe we could 
go over them together sometime today? Or you could point me to the 
suspicious results in the file... 

It shows the same real errors and also reports the 2 i/p mux problem: 

Reason: Two e inputs. Use diff. instead 
exclusive inputs 

instance path: top.xnbdbufdout47 .nbdbufxselaOablpehl 

cellname path: top.eam2ffdhl6sl lx2a.sel_alpeh_I 

instance path: top.xnbdbufdout47 .nb_dbuf_xselaO_ablpeh_0 

cellname path: top.eam2ffdhl6sl lx2a.sel_alpeh_0 
drivers 

instance path : top.xnbdbufrselbufl .nb dbuf xselaO ab 1 peh_ 1 
cellname path: top.ealplqh3s4x2a .q_blph 
instance path: top.xnbdburrselbuf0.nb_dbuf_xselaO_ablpeh_0 
cellname path: top.ealplqh3s4x2a .q_blph 
exclusive topmost nets 

instance path: top.nb_dbuf_xselaO_ablpeh_l 
cellname path : top.nb dbuf xselaO ab 1 peh_ 1 
instance path : top . nb_dbuf_xselaO_ab 1 peh_0 
cellname path: top.nb_dbuf_xselaO_ablpeh_0 

For some reason there is a lot less output accociated with this. 

The tlb problem is gone in fred's version. 

The reported short in cc that I couldn't see is still reported but the bogus 
error message that I was seeing is gone. 
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From: vo (Tom Vo) 

Sent: Wednesday, March 01, 1995 1:14 PM 

To: 'Lisa Robinson' 

Cc: 'geert (Geert Rosseel)' 

Subject: Re: forwarded message from "andrew" 


Lisa Robinson wrote .... 
> 

> Start of forwarded message 

>Status: RO 

>X-VM-v5-Data : ([nil nil nil nil nil nil nil nil nil] 

> ["838" " " "28" "February" "1995" "14:32:33" "-0800" " \ " andrew\ " " 
"andrewOcharybdis" nil "16" "Cerberus Stuff" ,,A From: " nil nil "2"]) 
>Re turn- Path: <andrew®charybdis> 

>Received: from charybdis (charybdis.microunity.com) by 
gaea . microunity . com (4 . 1/musel .3) 

> id AA2914 0; Tue, 28 Feb 95 14:31:07 PST 
>Message-Id: < 95 022 8223 1 .AA29140@gaea. microunity . com> 
>From: "andrew" <andrew@charybdis> 

>To: "Lisa Robinson" <lisar@gaea> 

>Subject: Cerberus Stuff 

>Date: 28 Feb 1995 14:32:33 -0800 

> 

>Lisa 

>Do you know what controls the following calliope pads. I've gone 

> through 

the 

>Terp doc but could find no mention of them. Also, I think the last 

>one, au_loop is in fact a Hermes control and not cerb as the name implies. 

> 

> Andrew 


>t2cfg0_abm padttl 

# 

Spare 

cerberus 

controlled 

pads 

for 

future 

applications 








>t2cfgl_abm padttl 


Spare 

cerberus 

controlled 

pads 

for 

future 

applications 








>t2cfg2_abm padttl 

# 

Spare 

cerberus 

controlled 

pads 

for 

future 

applications 








>t2cfg3_abm padttl 

# 

Spare 

cerberus 

controlled 

pads 

for 

future 

applications 








>t2cfg4_abm padttl 

# 

Spare 

cerberus 

controlled 

pads 

for 

future 

applications 








>t2cfg5_abm padttl 

# 

Spare 

cerberus 

controlled 

pads 

for 

future 

applications 








>t2cfg6_abm padttl 


Spare 

cerberus 

controlled 

pads 

for 

future 

applications 








These are controlled by bits 62 

56 of cerberus octlet 13 




>auloop_abm padttl # Spare cerberus controlled pads for future 

applications 

This is controlled by bit 3 of AI device register . 


tvo 
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Subject: 


Sent; 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Wednesday, March 01, 1995 1:41 PM 
'Kurt Warn pier' 
'geert (Geert Rosseel)' 
Re: Re-running global route 


Kurt Wampler writes: 

I ended up with a corrupt dff after my global route attempt; not sure why. 
I started this time with an empty dff (instead of derouting the 98% -routed 
dff) and it's running again on medusa. Should be done before 6:30PM, so I'll 
check on it from home later this evening. If you want to have a look, it's 
in /n/godzilla/s2/wampler/gloroute/geert_euterpe- iter .dff ... 


Looks like it finished at 18:29. That's a pretty good call, Kurt! 
Haven't had a chance to look at it yet. . . 


-hopper 
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From: hopper (Mark Hofmann) 

Sent: Wednesday, March 01 , 1995 2:58 PM 

To: 'Lisa Robinson' 

Cc: 'tbr (Tim B. Robinson)'; 'sysadm' 

Subject: Re: vlit 

Lisa Robinson writes: 
Help! 

I still can't run vlit .... 

tail makerrs 

sed -e 's/.ntf//' -e 's@.*/@@' > vlit_cell_list 

cat /n/rhodan/s3/euterpe/proteus/ikos/lib/raralist » vlit_cell_list 

INTERHDL_ELMHOST=rhea 
INTERHDL_KEY_DIR=/n/rhodan/s3/euterpe/tools/vendor/ikos/vlit.2_5/vlitkeys /n/rhodan/s3/euterpe/tools/bin/v1 it 1 cat 
ikosjist' -scelljist -v -r0.05 -e -s vlit cell list 

Checking out license... 

===== interHDL vlit version 2.5 

(c) Copyright 1992-1994, interHDL inc 

Server rhea [04]: Insufficient servers running, 
gmake: *** [compv] Error 1 

Lisa- 
please kill process 2263 1 on rhea and I will attempt a re-start 
-hopper 
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From: doi {Derek Iverson) 

Sent: Wednesday, March 01 , 1 995 3:34 PM 

To: 'guarino'; 'sandeep'; 'gmo'; 'jeffm'; 'wayne' 

Cc: 'hestia' 

Subject: Software Bringup Meeting Minutes - March 1, 1995 


Software Bringup Meeting 


March l, 1995 
Next Meeting: March 8 at 10:00 am. 

Attendees: guarino, gmo, sandeep, jeffm, doi 


New Action Items 


Item: Build a longer sync-op test with nb activity. 
Who: guarino 
Status: New 

Item: Build and run stress test (without printfs) 
Who : guarino 
Status: New 

Item: Build test that accesses and runs in a bunch or memory spaces and 
states . 
who : doi 
Status: New 

Item: Can a single cylinder (in an exception "loop') lock out other 
cylinders? 
Who: jeffm 
Status : New 

Item: Determine what is initialized (and how) in terp 
Who : guarino 
Status : New 

Review of Action Items 


Item: Terp needs to model "guaranteed forward progress for cache miss 1 

in the same fashion as the hardware does. 
Who: lisa 

Status: In progress. 

03/01 Lisa has contacted mws and is implementing the same scheme 
used by the hardware . 


Item: Tests need to be written to verify performance issues 
Who : lisar 

Status: In progress. 

02/22 We need to flag performance problems as errors. 

Tests could be identified (and perhaps written) to measure 
and verify performance of the hardware for things like cache 
misses, tlb initialization, exceptions, etc. 


Exhibit C12 


Page 10 of 


03/01 Lisar has started writing these tests. 


Item: Running Real-time Benchmark on Euterpe /Calliope HW Simulator 

(combined with previous "Run real-time test on the HW simulator) 
Who: gregg, lisar 
Status : In Progress . 

02/08 There are problems getting the benchmark to run on the 
software simulator. Work continues to find out where 
the problems are. The compilers, simulator, kernel, and 
benchmark areas are "frozen' (in terms of checking in 
new changes) until the problem has been identified. 

02/15 It is estimated that by the middle of March we should have 
cycles available on the IKOS and a IKOS compatible calliope 
that can be run with the real-time benchmark. 
Lisar will be the verification resource to help with running 
this application. 

The benchmark is working and now the effort is focused on 
getting it to fit in the real-time and memory budgets. 
03/01 The TV application has bogged down recently but work 
continues . 

It is believed that this won't be ready to run (from the software 
hand the hardware perspective) until April. 


Item: Specify and Design ISA/Cerberus Card 
Who: gmo, lisar, dbulfer 
Status: Pending 

02/22 gmo, lisar, and dbulfer own the problem of specifying 

the design and assigning resources. 
03/01 The specification meeting happened but design (hw and sw) has 

yet to begin. 


Item; Determine what additional terp features are required 

(formally "Status of Euterpe/Mnemo simulation') 
who: gmo, jeffm 
Status: Pending. 

02/08 Jeffm figured that in 2 - 3 weeks time there would be a need 

for terp/mnemo capability to support the verification effort. 

An issue was raised that this may not be enought time for the 

required additions to terp to be made . 
02/15 Gmo is to create a list of requested features for terp and 

then he and jeffm (and others?) are to review the list and 

determine what will be implemented by terp. 
02/22 Gmo is ready to circulate the list. 
03/01 Nothing new. 


Item: Test interleaved access 
Who: guarino, lisar 
Status : Pending . 

02/08 Loretta started to look at this but requires terp support. 

Terp changes are on hold until the real-time benchmark is 

is running again. 
02/22 Test has been written (interleave) but has not been run on 

hwterp yet. Lisar is going to run this on the hardware simulator. 
03/01 The test has been built, but not run yet. Derek is to check 

to be sure the hermes channels are enabled. 


Item: Build microkernel tests for IKOS 
Who: doi, sandeep, iimura 

Status: In progress. Expected completion 2/15 
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02/08 Create images for boot test, snapshot images for microkernel 
tests . 

02/15 doi is still working on modifying the makefiles to build 
the _1 and _2 versions of this. 

iimura is creating a tool that modifies the ELF headers to 
have the proper real addresses {not just virtual) and gmo has 
modified mkimg to be able to understand the new headers. 

02/22 lisar says there are still problems building this. 

iimura is generating a code segment that will run in both 
rom and cerbrom that will proberly initialize dram 
and then branch to the test {which is in dram) . 

03/01 Sandeep is going to add code to boot so it can figure out 
if the cerb node is zero or eight. 

Derek is to start building the kernel tests so they may be 
loaded and run on the hw simulators. 


Item: DVT boot 

Who : sandeep 

Status: In progress. 

02/08 First step is to get nano-boot running on the HW simulator. 
02/15 Sandeep has completed the boot code and now we need to 

build a dvt that can be loaded by the DVT boot {i.e. it 

is loaded into the top 8K of D and I buffer) . 

Jeffm commented that for most DVTs, they must be loaded at 

the beginning of D and I buffer and the beginning of ram. 

We will have to come up with an alternative for loading DVTs. 

Sandeep noted that dvts will not be started in event mode 

which is in contrast to jeffm' s mail about the initial state 

for dvts (but we knew this already) . 
02/22 We want to understand if we can modify the DVTs so they do not 

require that they are loaded at the beginning of D&lbuf and ram. 
03/01 Sandeep is going to implement a DVT boot mechanism. 


Suspended Items 


Item: Unsnap code 

Who : sandeep , guarino 

Status: Suspended. 

02/15 The issue of restarting the hardware from an IKOS dump 

was discussed and the need for an architectural snap/unsnap 
facility was questioned. 

Since the meeting it has been re -discovered (jeffm wasn't there 
to remind us of an earlier decision) that we are planning on 
loading architectural state into an IKOS simulation and not 
from a total IKOS logic dump. 

We also determined that when it came time to run some 
of the larger tests (real-time benchmark) we would need 
the capability to start an IKOS simulation from an 
architectural dump anyhow. 
03/01 For the short term we are going to focus on a simpler 
approach for loading and running DVTs, the kernel, and 
kernel tests. This item will likely come back in April. 


Item: Refine remote debugging environment 
Who : sandeep 
Status: Suspended 

02/08 We have to decide how control (and state) is to be returned 
to the debug stub after a test runs. 
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02/15 Sandeep is not going to have time to start on this for a while. 


Item: Create performance test plan 
Who: jeffm, guarino 

Status: [11/30] No progress as focus is on functionality. 


We continue to run tests to help us compare terp vs hardware 
performance . 

We still need to put together the actual performance tests that 
need to be run on the hardware. 


Completed Items 


Item: Current hardware traces should capture the "nb full 1 signal 
Who: jeffm, lisar 
Status: Done. 

03/01 Jeff has introduced 4 new signals to some of the dump files 

(this will be propogated to others). There are two "nb full 1 
signals, a gtlb hit, and the memory management enabled signals 
captured now. 


Test Status and General Discussion 


Jeffm reports that we have enjoyed significant test success recently. 

Both jeffm and djc's sync tests pass. Jeffm is currently chasing bugs related to off -chip 
Ifetch. 

It is estimated that test focus will shift to running boot and kernel tests during the 
week of March 7 - 13 . 

Lisar is spending time getting boot from cerberus working and simple performance tests 
running . 

There was some discussion of how we could classify certain tests to determine if they were 
capable of being loaded by nanoboot (dvtnanoboot) or if they required boot. 

nanoboot - can load onchip test, onchip data, and onchip 


bss . 


boot 


- in addition to the capabilities of nanoboot, it 


can 


understand ELF files and preload dram. 
- boot currently takes the top 8K of I and D buffer 
(and may be moved to the top 4K if we need 


space) 


and as a result leaves 24K of I and D buffer 
available for the DVT. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Wednesday, March 01, 1995 3:37 PM 

'warn pier (Kurt Wampler)'; 'vant' 

'geert (Geert Rosseel)'; "tbr (Tim B. Robinson)' 

Re: Global routing results 


Kurt Wampler writes : 

Well... I have a global routing result. Looks awfully dense in spots. 
Of the 

12,959 nets attempted, 174 failed to route completely in a M3/M4 linesearch 
pass. Among the global nets attempted, I count 95 busses of 10 or more bits 
which are still differential (just grepping for '_n<[0-9j [0-9]'). 

I think it might be interesting to have a large-scale plot of this global 
routing. To that end, in: 

/n/godzilla/s2/wampler/plot 

I have converted the results to Compass format so they can be plotted. 

Is 

there anything special I need to do to get the "gaudy" colors, or are those 
now the standard defaults for rplot? 


I think_ to get the gaudy colors you need to give 1 additional argument to rplot : 


Hmmm. . . 


-pdf /u/vanthof /compass/mobi/euterpe/plot/plot .pdf 


is that correct, Dave? 


-hopper 
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From: 


craig 

Wednesday, March 01, 1995 4:55 PM 

'dickson doi tbr' 

'euterpe' 

Re: Cerberus Node Number available in Exception Status Register 


Sent: 

To: 

Cc: 


Subject: 


My earlier elaboration didn't provide for desired security features of the Euterpe chip. 
In an earlier meeting I verbally describe a change, which may not have seen written form. 

The rule should be: 

if the node number is 0 or 1, boot from the flash ROM. 
if the node number is 2-255, boot from Cerberus node 0. 

The flash ROM needs to be accessable via Cerberus when node==0. 

When nodes=l, Euterpe should be "secure, " in that the contents of the flash ROM is not 
accessable via the Cerberus port. 

For 2<=node<=255 , it doesn't matter whether the flash ROM is accessable (it likely 
wouldn't be present anyway). 

Additional security would result if other Cerberus registers are made unwritable except by 
Euterpe itself; this is a less direct method of potential attack, as all one can do via 
the Cerberus registers is set the analog levels in parts of Euterpe and Hermes to 
something marginal, and hope that some resulting undetected error causes a security 
violation. However, given the level of effort which has been used to thwart cable boxes in 
the past, making this impossible is probably worthwhile. 


Craig 
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Sent: 

To: 

Cc: 


Subject: 


From: 


doi (Derek Iverson) 

Wednesday, March 01, 1995 5:04 PM 

'tor 1 ; 'craig' 

'euterpe' 

Cerberus Node Number available in Exception Status Register 


My understanding is that bits 55.. 48 of the exception status register are going to contain 
the cerberus node number (presumably bits 63 . . 56 are still zero). 

Thus, in the current implementation, if this value is 0x08 (or if it is 
non-zero? ) 

then we are booting from cerbrom, if this value is 0x00 then we are booting from rom. 
Can you confirm this? 


Thanks , 
Derek 
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From: 
Sent: 
To: 

Subject: 


mws (Mark Semmelmeyer) 
Wednesday, March 01, 1995 6:47 PM 
'doi'; 'jeffm'; 'lisar' 

Recommended PC+PL to use for IKOS/Zycad 


I can't find a single vector midpipe PC, but I think I found a better endpipe PC than the 
WP version you are using now. 

It is the next- sequential PC (including that the job is completely released) and 
corresponds to the R19 stage of the pipe, becoming the R14 for the next job. By using it 
as R14, we get a PC before the branch updates itself with its target. The net name is: 

euterpe/rg/rgpc/pcPlIncWR [63 : 0] 
The driving flop instance names for bit 63 downto 0 are: 

euterpe/rg/rgpc/UpdncWP/Uinc {7,6,5,4,3,2,1} /Us/u{ 7,6,5,4,3,2,1,0} 

euterpe/rg/rgpc/UpcIncWP/UincO/Us/u{5,4, 3 ,2, 1, 0} 

euterpe/rg/rgpc/UpcPlIncWR/u{l, 0 } 
I can change the levellog program to match. Let me know. 

If you are happy with this change, I can change the verilog wrap. log strobe statements to 
print the same PC to make verilog and ikos/zycad compare more readily. Or maybe I should 
do this 1st on verilog to prove it works, although then I would like a commitment that we 
would follow up on ikos/zycad. 

What do you think? I think this would eliminate 1 source of confusion and speed debug. 


thanx , 


mark 
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From: 
Sent: 
To: 

Subject: 


warn pier (Kurt Wampler) 
Wednesday, March 01, 1995 8:02 PM 
'geert'; 'hopper' 
Re-running global route 


I ended up with a corrupt dff after my global route attempt; not sure why. 

I started this time with an empty dff (instead of derouting the 98% -routed 

dff) and it's running again on medusa. Should be done before 6:30PM, so I'll check on it 

from home later this evening. If you want to have a look, it's in 

/n/godzilla/s2/wampler/gloroute/geert_euterpe-iter.df f . . . 


- Kurt 
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Sent: 


To: 


Cc: 


From: 


lisar (Lisa Robinson) 

Wednesday, March 01, 1995 10:34 PM 

'hopper 1 ; 'tbf 

'sysadm' 


Subject: Re: vlit 
Help! 

I still can't run vlit .... 

tail makerrs 

sed -e 's/.nttf/' -e 's@.*/@@' > vlit_cell_list 
cat /n/rhodan/s3/euterpe/proteus/ikos/lib/ramlist » vlit cell list 
INTERHDL_ELMHOST=rhea 

INTERHDL_KJEY_DIR=/ri/rhodan/s3/euterpe/tools/vendor/ikos/vlit.2_5/vlitkeys /n/rhodan/s3/euterpe/tools/bin/vlit 'cat 
ikosjisf -scelljist -v -r0.05 -e -s vlit_cell_list 
Checking out license... 

interllDL vlit version 2.5 ==== 

(c) Copyright 1992-1994, interHDL inc 

Server rhea [04]: Insufficient servers running, 
gmake: *** [compv] Error 1 
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From: vanthof (vant) 

Sent: Thursday, March 02, 1995 12:04 AM 

To: 'Mark Hofmann' 

Cc: 'wampler (Kurt Wampler)'; 'vant'; 'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)' 

Subject: Re: Global routing results 


Mark Hofmann writes: 
>HmTnm . . . 

> 

> I think_ to get the gaudy colors you need to give 1 additional 
>argument to rplot: 

> 

> -pdf /u/vanthof /compass/mobi/euterpe/plot /plot .pdf 
> 

>is that correct, Dave? 
> 

>- hopper 


Yes, I have not installed these or added a new switch to call them automatically yet. 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 


Exhibit C12 


Page 20 of 643 


Subject: 


Sent: 

To: 

Cc: 


From: 


warn pier (Kurt Warn pier) 

Thursday, March 02, 1995 12:06 AM 

'hopper@hestia.microunity.com'; Vanthof 

'geert'; 'tbr*; 'vant' 

Re: Global routing results 


©Mark Hofraann writes : 

@>Hmmm. . . 

@> 

@> I _think_ to get the gaudy colors you need to give 1 additional @>argument to rplot: 
@> 

@> -pdf /u/vanthof/compass/mobi/euterpe/plot /plot .pdf 

@> 

@>is that correct, Dave? 
@> 

@>- hopper 


©Yes, I have not installed these or added a new switch to call them ©automatically yet. 

© 

©Dave 

Thanks for confirming, Dave. I've submitted a plot with this additional 
qualifier, so if everything works as planned, it'll be waiting for us in 
the morning. 


@ 
@ 


- Kurt 
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From: 


tbr 


Sent: 


Thursday, March 02, 1995 12:15 AM 
'doi (Derek Iverson)* 
'craig'; 'dickson'; 'euterpe' 

Cerberus Node Number available in Exception Status Register 


To: 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Derek Iverson wrote (on Wed Mar 1): 


My understanding is that bits 5 5.. 48 of the exception status register 

are going to contain the cerberus node number (presumably bits 63.. 56 are 

still zero). 

That's the plan, but we haven't managed to find room to route the 
extra wires out of Cerberus yet . . . 

Thus, in the current implementation, if this value is 0x08 (or if it is non-zero?) 
then we are booting from cerbrom, if this value is 0x00 then we are booting from 
rom. 

Can you confirm this? 


The current rev of Heastia only brings bit 3 of the Cerberus address 
to the expansion connector, so 0 and 8 are the only choices there. 
However, the Euterpe itself should boot from Cerberus whenever the address 
is non zero. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Thursday, March 02, 1995 12:15 AM 

'doi (Derek Iverson)' 

'craig'; 'dickson'; 'euterpe' 

Cerberus Node Number available in Exception Status Register 


Derek Iverson wrote (on Wed Mar 1) : 


My understanding is that bits 55.-48 of the exception status register 
are going to contain the cerberus node number (presumably bits 63.. 56 are 
still zero) . 

That's the plan, but we haven't managed to find room to route the extra wires out of 
Cerberus yet . . . 

Thus, in the current implementation, if this value is 0x08 (or if it is 
non-zero?) 

then we are booting from cerbrom, if this value is 0x0 0 then we are booting from 
rom. 

Can you confirm this? 


The current rev of Heastia only brings bit 3 of the Cerberus address to the expansion 
connector, so 0 and 8 are the only choices there. 

However, the Euterpe itself should boot from Cerberus whenever the address is non zero. 


Tim 
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From: 
Sent: 
To: 

Subject: 


tbr (Tim B. Robinson) 

Thursday, March 02, 1995 12:31 AM 

'craig'; 'dickson'; 'doi (Derek Iverson)'; 'euterpe' 

Cerberus Node Number available in Exception Status Register 


Tim B. Robinson wrote {on Wed Mar 1) : 


The current rev of Heastia only brings bit 3 of the Cerberus address 
to the expansion connector, so 0 and 8 are the only choices there. 
However, the Euterpe itself should boot from Cerberus whenever the address 
is non zero . 

According to Craig's most recent posting, this behavior will have to change so 0 and 1 are 
equivalent for boot source selection. 


Tim 
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From: 


tbr 


Subject: 


Sent: 
To: 

Cc: 


Thursday, March 02, 1995 12:33 AM 
Vo (Tom Vo)' 

'rich (Rich McCauley)'; 'hopper' 
pl_mne in /u/chip/proteus/verilog/ged 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Vo wrote (on Wed Mar 1): 


1 can't find pl mne.v in /u/chip/proteus anymore . 
It used to be under /u/chip/proteus/verilog/ged but 
no more . 

Yes. I don't know how the last one went away, but it is related to 
the facts that 

1 . Rich M released a new version 

2. I did a release in proteus/ged which probably backed out his 
release 

3. My .checkoutrc failed for some reason which hopper was 
investigating 

Still doesn't explain what removed the old version. 

I'll try getting it back now, meanwhile you can point the the snapshot 
euterpe proteus. 

Mark, did you discover what was the cause of that missing script. 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Thursday, March 02, 1995 5:04 AM 

To: 'billz'; 'jeffm'; 'woody' 

Cc: 'dickson'; 'mws'; 'tbr' 

Subject: dcacheharder4 

Dump is on staypuft /s3/tbr/euterpe/verilog/bsrc 
Lisa R. 
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From: lisar (Lisa Robinson) 

Sent: Thursday, March 02, 1 995 5:27 AM 

To: 'jeffm'; 'mws' 

Cc: W 

Subject: exlocktest 


verify c_euterpe_wrap -group exlocktest -srl likedriverlog -resdir 1395.21364 
Warning: Not logging these results. 
Summary file is res/1 395.2 1364/summary 


Design Name: ceuterpewrap 
Run Date: 1395 
Run ID: 21364 


Simulator: c_euterpe_wrap.mif.mm was built on Wed Mar 1 13:25:10 1995 

Using BOM: Version BOM,v 241.0 1995/03/01 01:12:22 LT mws 
Warning: Local BOM is out of date ... 
Log Message: 

Run started on host: nosferatu at: Wed Mar 1 20:56:05 PST 1995 

exlocktest_0 Processing exlocktestj) .... Ran ok 
Run time = 1.544e+04 seconds Performance = 16 cycles/second 


No PR of 1395.21364 filed with gnats so mailing res/1 395.2 1364/summary to you 
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From: vanthof (vant) 

Sent: Thursday, March 02, 1995 11:05 AM 

To: 'hopper (Mark Hofmann)'; 'vo (Tom Vo)'; 'lisar (Lisa Robinson)'; Tim B. Robinson'; 'Geert Rosseel' 
Cc: Vanthof (Dave Van't Hof)'; 'torn (Thomas Laidig)' 
Subject: euterpe metal drcs 

The snapshot metal drc's are still clean. The only 'notch' failures left 
are 5 from the via twinning post processing phase, one of those is still 
the bizarre clock wire in front of the cr block. 

The lowers are still running and should be done in a day or so. 

so far so good. 

Thanks, 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> 
Don't blame me, I didn't vote for him! 
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From: hopper (Mark Hofmann) 

Sent: Thursday, March 02, 1995 2:46 PM 

To: 'geert (Geert Rosseel)' 

Subject: euterpe ctioi 


hi geert, 

In your euterpe mail you say: 

3. look at i-cache strip, starting at ctioi 

What should I look for there? What things are candidates to push around? 

- thanks , 
mark 
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From: lisar (Lisa Robinson) 

Sent: Thursday, March 02, 1995 3:17 PM 

To: 'sysadm' 

Subject: Need to run voyager .... 


lisar@rhodan /s3/euterpe/verilog/bsrc 486 % voyager 


Voyager System Software 2.00L CS/CSX Oct 17 1994 
RGP: WARNING - Invalid font handle (vddQueryFontExtent) 
RGP: WARNING - Invalid font handle (vddQueryFontExtent) 
RGP: WARNING - Invalid font handle (vddQueryFontExtent) 
RGP; WARNING - Invalid font handle (vddQueryFontExtent) 
RGP: WARNING - Invalid font handle (vddQueryFontExtent) 
RGP: WARNING - Invalid font handle (vddQueryFontExtent) 
Arithmetic exception (core dumped) 

Lisa R. 
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From: geert (Geert Rosseel) 

Sent; Thursday, March 02, 1 995 4:23 PM 

To: 'billz'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'tbr'; 'woody' 

Subject: Euterpe route 


Hi, 

I am going to build another top-level tomorrow evening. Here is what we've decided in 
today's meeting : 

1. swap rgxmit and hz . Improve uu placment for wires to 
rgxmit 

Geert, Jay 

2. cerberus wires at top-right of the die . 

Tom vo 

3. look at i-cache strip, starting at ctioi 

Hopper 

4 . GT and tlb wire assignment 

Tbr 

If dr is ready by tomorrow evening, I'll pick that up too. 

Geert 


Exhibit C12 


Page 31 of 643 


From: lisar (Lisa Robinson) 

Sent: Thursday, March 02, 1 995 4:30 PM 

To: 'ericm (Eric Murray)' 

Cc: 'sysadm' 

Subject: Re: Need to run voyager .... 


Eric Murray wrote (on Thu Mar 2): 

Lisa Robinson wrote: 

> 
> 

> lisar@rhodan /s3/euterpe/verilog/bsrc 486 % voyager 

> 
> 

> Voyager System Software 2.00L CS/CSX Oct 17 1994 

> RGP: WARNING - Invalid font handle (vddQueryFontExtent) 

> RGP: WARNING - Invalid font handle (vddQueryFontExtent) 

> RGP: WARNING - Invalid font handle (vddQueryFontExtent) 

> RGP: WARNING - Invalid font handle (vddQueryFontExtent) 

> RGP: WARNING - Invalid font handle (vddQueryFontExtent) 

> RGP: WARNING - Invalid font handle (vddQueryFontExtent) 

> Arithmetic exception (core dumped) 

lisa, could you provide more information when you have a problem? 
unfortunately since we don't actually work with the software 
packages that you use, or even understand what they do, there's 
a lot of background that we lack, you tend to send very short 
messages which often do not explain very well what the 
problem is, or even include enough information to 
be able to make a test, in this case i have no idea 
where 'voyager* is, since it's not in your $PATH. 
i don't know what it is either, all i can surmise is that 
it's an X app. but even then i'm stuck, since i have no 
clue what RGP is or what sort of font vddQueryFontExtent 
might want. 

unfortunately it's a typical human tendency when given incomplete 
or difficult to figure out messages to say to one's self "i don't 
know what this is, i'U look at it later", so your requests 
get dropped to the end of the queue, after the ones that i 
have enough information to solve. 

Sorry eric. I knew ken would know what to do as he fixed it for me a 
couple of days ago. I'm not sure I understand exactly what it wrong as 
I expected it to be fixed but it was related to a file 
(bootp?) on the auspex not having the correct address of my hds (it 
had the old address). 

Ken then wrote a script addfont in my home directory whch gives me a 
temporary workaround. 

Lisa R. 
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From: geert (Geert Rosseel) 

Sent: Thursday, March 02, 1995 6:58 PM 

To: 'billz'; 'hopper 1 ; 'mws'; 'tor'; 'vo*; 'wampler'; 'woody' 

Subject: geert_euterpe-iter.dff 

Hi, 

I moved the dff file to verilog/bsrc/gards2 . 
Geert 
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From: 
Sent: 
To: 

Subject: 


paulb (Paul Berry) 

Thursday, March 02, 1995 8:28 PM 

'pandora' 

ISA-Cerberus IF (Feb 24 mtg) 


Summary of ISA/ Cerberus Requirements (Meeting 2/24/95) 

> General read/write to Cerberus. 

> Receive Cerberus read/write to a single node, 
address programmed via the ISA bus . 

> Generate reset . 

> No DMA. Programmed I/O and Interrupt are good enough. 

> No local memory. 

> 20 Mbits/sec to Cerberus. 

> ISA address and IRQ selectable via DIP switch. 

> Connector on ISA like and RJ-45. 

> Hardware speaks byte- level protocol to Cerberus. 
Software translates to the higher- level interface. 

> Errors on Cerberus are handled via software. 

> Sideband able to generate errors. 

> Option: ability to receive Cerberus packet at any node address. 


Pandora Notes 


A somewhat more detailed account of the discussion is in the Pandora Notes. 
To see them: from a Unix shell, execute: 
central 

Click: MediaComputer Specs / Pandora / Meeting notes. 

That gives you the table of contents. For the latest entry, scroll to the end. 
Click: February 24, 1955 

(or any other heading you want) . 
That displays the topic you click. 
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From: lisar (Lisa Robinson) 

Sent: Friday, March 03, 1995 2:43 AM 

To: 'hopper'; 'sysadm' 

Subject: vlit down 

I will restart it .... 

lisar@nosferatu /s2/euterpe/verilog/bsrc 421 % vlit 

interHDL vlit version 2.5 ===== 

(c) Copyright 1992-1994, interHDL inc 

Checking out license- 
Feature 04: License server is down. 
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From: 
Sent: 
To: 

Subject: 


tbr 


Friday, March 03, 1995 2:56 AM 

'geert' 

gt etc 


Follow Up Flag: Follow up 
Flag Status: Red 


Unfortunately we got a visitor this evening, so I've not had much time 
so far. 

First I thought I'd build a gt locally then put a top level together 
with just that and the gtlb so I can see just the nets of interest. 

gt iterated fine, but then I found myself having to hack at genpim2.pl 
and Makefile.tst etc to set this up with just the stuff i needed. On 
mnemo I have is set up so we can have multiple GARDS_SUBDIRS lists 
just like we have multiple exclude lists, and torn, alan and myself are 
now all able to do our own thing without stepping on each other. It's 
fairly easy to do. Should we retrofit this to euterpe? 

Looking at the plot kurt made of the gt area it's very clear we have a 
really bad placement. One thing though is that the registers on the 
main output of the gtlb are placed right next to it (the output 
latches are unbuffered) and I'd like to swap them with the snake stuff 
because there are more wires going to that. Although this may 
introduce a little extra delay (thouth I think with a good placement 
the wires will be no longer on these outputs), I am thinking this is 
probably OK, since the gtlb was designed assuming 1 .29GHz and so must 
have some slack. What do you think? I's expect to add I50u of M3 at 
most. 


Tim 
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From: 
Sent: 
To: 

Subject: 


tbr (Tim B. Robinson) 

Friday, March 03, 1995 2:56 AM 

'geert' 

gt etc 


Unfortunately we got a visitor this evening, so I've not had much time so far. 

First I thought I'd build a gt locally then put a top level together with just that and 
the gtlb so I can see just the nets of interest. 

gt iterated fine, but then I found myself having to hack at genpim2.pl and Makefile. tst 
etc to set this up with just the stuff i needed. On mnemo I have is set up so we can have 
multiple GARDS_SUBDIRS lists just like we have multiple exclude lists, and torn, alan and 
myself are now all able to do our own thing without stepping on each other. It's fairly 
easy to do. Should we retrofit this to euterpe? 

Looking at the plot kurt made of the gt area it's very clear we have a really bad 
placement. One thing though is that the registers on the main output of the gtlb are 
placed right next to it (the output latches are unbuffered) and I'd like to swap them with 
the snake stuff because there are more wires going to that. Although this may introduce a 
little extra delay (thouth I think with a good placement the wires will be no longer on 
these outputs) , I am thinking this is probably OK, since the gtlb was designed assuming 
1.29GHz and so must have some slack. What do you think? I's expect to add 150u of M3 at 


most . 


Tim 
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From: geert (Geert Rosseel) 

Sent: Friday, March 03, 1995 1 0:34 AM 

To: W 

Subject: Re: gt etc 

> Should we retrofit this to euterpe? 

Yes, that's been on my list of things to do for a long time. 

> What do you think? 

The GTLB is quite over-designed, so we should have some margin there. 
Geert 
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To: 


From: 


Sent: 


vo (Tom Vo) 

Friday, March 03, 1995 12:55 PM 
'ericm (Eric Murray)' 


Cc: 'tbr (Tim B. Robinson)'; 'hopper (Mark Hofmann)' 
Subject: dead in the water 

My make does not run on ghidra any more . It keeps getting 
the path wrong . 

Sample error message : 

gmake: *** No rule to make target 7n/ghidra/N/ghidra/s4/vo/euterpe/veriry/Makefile.rules'. Stop 

The files are on ghidra s4 disk , I noticed that s4 is referenced differently now , 
If I cd to /n/ghidra , s4 is now a link pointing to /N/ghidra/s4/ . 

The make would run on machines other than ghidra however . 

Any suggestion ? 


tvo 
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From: vo (Tom Vo) 

Sent: Friday, March 03, 1995 1:10 PM 

To: 'Eric Murray' 

Cc: 'tbr (Tim B. Robinson)'; 'hopper (Mark Hofmann)'; 'torn (Thomas Laidig)' 
Subject: Re: dead in the water 

Eric Murray wrote .... 

> 

>Tom Vo wrote: 

» 
» 

» My make does not run on ghidra any more . It keeps getting 
» the path wrong . 

» 

» Sample error message : 

» gmake: *** No rule to make target 7n/ghidra/N/ghidra/s4/vo/euterpe/verify /Makefile. rules'. Stop 

» 

» The files are on ghidra s4 disk . I noticed that s4 is referenced differently now . 
» If I cd to /n/ghidra , s4 is now a link pointing to /N/ghidra/s4/ . 

» 

» The make would run on machines other than ghidra however . 

» 

» Any suggestion ? 

> 
> 

>huh? 

> 

>i get: 

> 

>ghidra:/n/auspex/s 1 7/ericm 

>ericm {105}> Is -Is /n/ghidra/s4/vo/euterpe/veriry/Makefile 

> 1 Irwxrwxrwx 1 vo 31 Oct 4 12:50 /n/ghidra/s4/vo/euterpe/verify 
>/Makefile -> /u/chip/euterpe/verify/Makefile 

> 
> 

>what's generating the target C/n/ghidra/N/ghidra/s4/vo/eute...') 
>in the first place? 

> 
> 

>i rdisted new amd maps today which change the semantics of the mounts slightly. 
>but if you've followed the rules (don't use /N in anything) 
>and don't use relative links which cross mounted filesystems 
>then there should be no problems. 

> 

>i did test extensively and didn't see anything like this. 

> 

>are you using something that expects there to be 

>an /N/ghidra/root? 

> 

> 

>-- 

> ericm ericm@microunity.com 

> 
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I think the path came from another script , abspath , to figure out where I am 

On ghidra , abspath gives : 
/n/ghidra/N/ghidra/s4/vo/euterpe/verilog/bsrc 

But on any other machine , the same command gives : 
/n/ghidra/s4/vo/euterpe/verilog/bsrc 

tvo 
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To: 


Sent: 


From: 


torn (Tom Laidig (tau)) 

Friday, March 03, 1995 1:54 PM 

'Eric Murray' 


Cc: 'vo (Tom Vo)'; 'tbr (Tim B. Robinson)'; 'hopper (Mark Hofmann)'; 'tau' 
Subject: Re: dead in the water 

Eric Murray writes: 

I 

|Tom Vo wrote: 


j> I think the path came from another script , abspath , to figure out where I am 


j> On ghidra , abspath gives : 
j> /n/ghidr a/N/gh idra/s4/vo/euterpe/veri log/bsrc 

l> 

|> But on any other machine , the same command gives : 
|> /n/ghidr a/s4/vo/euterpe/verilog/bsrc 

I 
! 

|the abspath in /a/muse/bin/ is broken. 

juse the one in /usr/local/bin, 

I 

I 

jBTW, it's silly to have N versions of the same thing, 
[there's 2 abspaths, plus /usr/local/bin/pwd, all of 
| which do the same thing. 

Well, the /a/muse stuff is pretty old. We were keeping it around 
intentionally for historical reasons, since some of our snapshots 
contained explicit references to /a/muse/bin. Perhaps that's 
sufficiently ancient history that we can blow it away; I'm not sure. 

/usr/local/bin/pwd is _not_ a replacement for abspath. abspath takes 
an optional argument directory, and returns an absolute path to that 
directory. In the process, any .. in the given path is interpreted a 
bit specially: if there is a .parent symlink, the .. gets translated 
as what .parent points to; otherwise the normal interpretation is used. 


I> 
l> 


l> 
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From: 


tbr 


To: 


Cc: 


Sent: 


Subject: 


Saturday, March 04, 1995 7:31 PM 

'geert' 

'wampler' 

net_sort 


Follow Up Flag: Follow up 
Flag Status: Red 

What is net sort? I see it used in Makefile.tst in euterpe 
but int is not parameterized and there is no definition in 
Makefile.defs. 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Saturday, March 04, 1995 7:31 PM 

To: 'geerf 

Cc: 'wampler' 

Subject: net_sort 


What is net_sort? I see it used in Makefile . tst in euterpe but int is not parameterized 
and there is no definition in Makef ile .def s . 

Tim 
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From: 


tbr 


Sent: 
To: 

Subject: 


Saturday, March 04, 1995 9:10 PM 

'geeif 

Makefile.tst 


Follow Up Flag: Follow up 
Flag Status: Red 


I'm checking in what I have, i have put back the stuff that appeared 
to be truncated from your checkin. 

My top level fails with: 

gmake[2]: Leaving directory '/N/auspex/root/slS/tbr/euterpe/verilog/bsrc' 

gmake CYCLETIME=926 gards/tbr_euterpe-iter.rload.1is 

gmake[2]: Entering directory '/N/auspex/root/slS/tbr/euterpe/verilog/bsrc' 

gmake[2]: *** No rule to make target *gards/tbr_euterpe-iter.rload.lis\ Stop. 

gmake[2]: Leaving directory '/N/auspex/root/slS/tbr/euterpe/verilog/bsrc 1 

gmakefl]: *** [tbr_euterpe-iter] Error 1 

rm tbr_euterpe. power. tab. local 

gmake[l]: Leaving directory */N/auspex/root/sl5/tbr/euterpe/verilog/bsrc' 
gmake: *** [tbr euterpegards] Error 1 

which is I assume because I do not have some sub-section stuff it's 
expecting now it's trying to do stuff for real. 

The only thing I'm worried about is the power. tab stuff since that's 
different from mnemo. Please let me know if you think I broke 
anything. 

Note, you will need to pick up genpim2.plat the same time. 


Tim 
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From: 
Sent: 
To: 

Subject: 


tbr (Tim B. Robinson) 

Saturday, March 04, 1995 9:10 PM 

'geerf 

Makefile.tst 


I'm checking in what I have. i have put back the stuff that appeared to be truncated from 
your check in. 

My top level fails with: 

gmake [2] : Leaving directory VN/auspex/root/sl5/tbr/euterpe/verilog/bsrc 1 
gmake CYCLETIME=926 gards/tbr_euterpe- iter . rload. lis 

gmake [2]: Entering directory * /N/auspex/root/sl5/tbr/euterpe/verilog/bsrc 1 
gmake[2]: *** No rule to make target "gards/tbr_euterpe- iter . rload . lis • . 
Stop . 

gmake [2]: Leaving directory *7N/auspex/root/sl5/tbr/euterpe/verilog/bsrc ' 
gmake [1] : *** [tbr_euterpe-iter] Error 1 rm tbr_euterpe . power . tab. local 
gmake [1] : Leaving directory " /N/auspex/root/sl5/tbr/euterpe/verilog/bsrc 1 
gmake: *** [tbr_euterpegards] Error l 

which is I assume because I do not have some sub- section stuff it's expecting now it's 
trying to do stuff for real. 

The only thing I'm worried about is the power. tab stuff since that's different from mnemo. 
Please let me know if you think I broke anything. 

Note/ you will need to pick up genpim2.plat the same time. 


Tim 
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From: 
Sent: 
To: 

Subject: 


wampler {Kurt Wampler) 
Saturday, March 04, 1995 9:59 PM 
'geert'; 'tbr' 
Re: net_sort 


tbr writes: 


>What is net_sort? I see it used in Makefile. tst in euterpe but int is 
>not parameterized and there is no definition in Makef ile . def s . 

It 1 s a shell script that sorts a list of netnames by: 
1} Subblock- internal nets {names contain a "/") 

2) Global nets 

3 ) Name 

4) Bus bit (if found) 

I was using it for my Euterpe routing experiments, and hopper checked 
it in while I was in the hospital. It can be invoked from /u/chip/tools/bin 
and he put the source in /u/chip/tools/src/gears . It would be OK to make 
a definition for it in Makef ile . def s; it expects to have /u/chip/tools/bin 
in its path, but other than that doesn't need special environment. 

I'm not sure I would have released it in its present form, but it's there 
now -- so I'll try to bring it up to standards if you see anything wrong 
with it. 


- Kurt 
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From: 


tbr 


Subject: 


Sent: 


To: 


Cc: 


Saturday, March 04, 1995 10:10 PM 
'wampler (Kurt Wampler)' 
'geert' 

Re: net_sort 


Follow Up Flag: Follow up 
Flag Status: Red 

Kurt Wampler wrote (on Sat Mar 4): 
tbr writes: 

>What is netsort? I see it used in Makefile.tst in euterpe 
>but int is not parameterized and there is no definition in 
>Makefile.defs. 

It's a shell script that sorts a list of netnames by: 

1) Subblock- internal nets (names contain a "/") 

2) Global nets 

3) Name 

4) Bus bit (if found) 

I was using it for my Euterpe routing experiments, and hopper checked 
it in while I was in the hospital. It can be invoked from /u/chip/tools/bin 
and he put the source in /u/chip/tools/src/gears. It would be OK to make 
a definition for it in Makefile.defs; it expects to have /u/chip/tools/bin 
in its path, but other than that doesn't need special environment. 

I'm not sure I would have released it in its present form, but it's there 
now -- so I'll try to bring it up to standards if you see anything wrong 
with it. 

Nothing wrong with it, it was just that I was cleaning up one of the 
euterpe Makefiles and I found it being invoked directly rather than 
through the usual definitions. Looks like we should add it to the 
standard Makefile.defs. 


Tim 
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Subject: 


From: 


Sent: 

To: 

Cc: 


tbr (Tim B. Robinson) 

Saturday, March 04, 1995 10:10 PM 

'wampler (Kurt Wampler)' 

'geeif 

Re: net_sort 


Kurt Wampler wrote (on Sat Mar 4) : 
tbr writes: 


>What is net_sort? I see it used in Makefile. tst in euterpe 
>but int is not parameterized and there is no definition in 
>Makef ile.def s. 

It's a shell script that sorts a list of netnames by: 

1) Subblock- internal nets (names contain a "/") 

2) Global nets 

3 ) Name 

4) Bus bit (if found) 

I was using it for my Euterpe routing experiments, and hopper checked 
it in while I was in the hospital. It can be invoked from /u/chip/tools/bin 
and he put the source in /u/chip/tools/src/gears . It would be OK to make 
a definition for it in Makef ile.def s; it expects to have /u/chip/tools/bin 
in its path, but other than that doesn't need special environment. 

I'm not sure I would have released it in its present form, but it's there 
now -- so I'll try to bring it up to standards if you see anything wrong 
with it . 

Nothing wrong with it, it was just that I was cleaning up one of the euterpe Makefiles and 
I found it being invoked directly rather than through the usual definitions. Looks like 
we should add it to the standard Makef ile . defs . 


Tim 
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From: wayne (Wayne Freitas) 

Sent: Monday, March 06, 1995 1 1 :31 AM 

To: 'arya'; 'rmm'; 'yves'; 'dane'; 'rich'; 'graham'; 'tbr'; 'pmayer'; 'philip'; 'noei'; 'woody'; 'tbe' 

Cc: 'hestia' 

Subject: Main board PR's 


Here is a list of Problem Reports that need to be taken care of, then closed before a 

Engineering Change Request (ECR) can be opened so we 

can begin work against the main board. I have cleaned up the PR's 

against this re- spin by providing a valid part number and assigning the a responsible 
engineer in the PCB category of gnats. If your name is in the first column you are 
responsible for seeing the PR through and 

having it closed. An ECR will be open in the next day or two against 
the main board. This is what Patty will be using as her check list of 
changes to be incorporated into the re- spin. The ECR requires that a 

PR be CLOSED in order for it to be added into the re -spin. If you have any questions or 
need a hand with gnat let me know and I'll drop by. 

Thanks 

Wayne 


17 71 woody PCB analyzed serious medium Decoupling 

cap connects to wrong plane 

17 72 noel PCB analyzed non-criti medium 

mount capacitor change to through hole 

17 74 pmayer PCB analyzed serious medium 

connector pins routing does not comply with UL requirement 

17 77 woody PCB analyzed serious medium 

ground pin connected to wrong ground 

17 91 pcbtcm PCB suspended critical high 

channel 3/4 BTSC conversion component; function needed in hw. 

17 92 woody PCB analyzed critical high 
ground for fan supply 

1799 pcbtcm PCB closed critical medium 

vias shorting to internal planes 

18 06 pmayer PCB analyzed serious medium 
power via too small 

1809 woody PCB analyzed 
fuse in fan connection to main pcb 

182 5 pmayer PCB analyzed 
dead traces on layer l and layer 3 

1826 pmayer PCB open 
Soldermask openings have exposed copper 

1827 pmayer PCB open non-criti 
Solder mask strips below 0.005" 

1828 pmayer PCB open non-criti low 
PTH in the center of TAB ground planes with no pads on solder 

1829 pmayer PCB open critical high 
clearances in internal layers 

183 0 pmayer PCB open serious medium 
Aspect ratio to high 

1831 pmayer PCB open serious medium 
Breakaway holes too close to copper layer 

1832 arya PCB closed serious medium Pin switch 
diodes should be moved onto the main board from the daughter boards 

1860 arya PCB analyzed serious medium Untied 
partial ground planes 

1861 woody PCB closed critical high Pinout 
problem on DC - DC Module 

1862 philip PCB analyzed serious high Fabrication 
error on the Main Board 

1869 wayne PCB closed non-criti low duplicate 


serious medium 


non-criti low 


non-criti low 


low 


Surface 
DC input 
IR receiver 
pcba missing 
Separate 
VCO ground 
Smart card 
Need to add 
Main Bd - 
Main bd - 
Main bd - 


Main bd 
side 
Main bd: 

Main Bd 

Main Bd 


PTH 
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reference designator 


18 7 6 pcbtcm PCB 

closed 

non-criti 

low 

Large solder 

pads . 





187 7 wayne PCB 

closed 

non-criti 

low 

Solder pads 

too small. 





18 78 pmayer PCB 

open 

critical 

medium 

Solder holes 

too small 





1879 pmayer PCB 

analyzed 

critical 

medium 

Missing 

holes on the PCB. 





188 0 pmayer PCB 

open 

non-criti 

low 

solder holes 

too large. 





18 81 pmayer PCB 

open 

critical 

high 

Extra solder 

holes . 





18 82 pmayer PCB 

open 

non-criti 

low 

Reference 

designator number. 





1901 yves PCB 

analyzed 

critical 

high 

Discrete 

components have open (floating) leads 



1902 pmayer PCB 

analyzed 

critical 

high 

Electrolytic 

caps on -5V layed out backwards 




1905 pmayer PCB 

open 

serious 

medium 

Duplicate 

ref designators (new ones) 





1909 arya PCB 

open 

critical 

medium 

Floating 

partial ground plane 





1910 pmayer PCB 

open 

serious 

medium 

Problems 

with the filter inputs to 

the contingency VCOs 



1911 rich PCB 

open 

critical 

high 

Power 

supplies for the external 

synthesizer filters need shielding and re- layout 

1914 pmayer PCB 

closed 

critical 

high 

DC -DC module 

-sense line shorted to +3. 

3V power plane 



1925 pmayer PCB 

analyzed 

serious 

medium 

solder pads 

too small 





192 9 arya PCB 

open 

critical 

high 


Descrepencies between BOM 

and Schematics 



193 0 arya PCB 

open 

critical 

high 

Incorrect 

designator used 





1931 pmayer PCB 

analyzed 

serious 

high 

Pads 

incorrectly spaced for SDRAMs 




1932 woody PCB 

open 

serious 

high 

Main board 

<-> Box clearance issue 





193 3 pmayer PCB 

analyzed 

serious 

high 

DC-DC 

fasteners short to trace 





1934 woody PCB 

open 

serious 

medium 

Reference 

descriptor incorrect 





1945 arya PCB 

open 

critical 

high 

Grounds 

missing in transformer amplifier region 



1946 arya PCB 

open 

critical 

high 

Missing 

ground on C22 5 (E30C2) 





1948 philip PCB 

closed 

serious 

low 

Main board 

has areas of possible delamination 




1950 pmayer PCB 

analyzed 

critical 

high 

Vias 

shorting the internal analog and digital ground layers 


1959 pmayer PCB 

open 

serious 

high 

Insufficient 

solder pad under vco's 





1960 pcbtcm PCB 

open 

serious 

medium 


Manuf acturability of attaching VCO's 

to main board 


1962 tbe PCB 

analyzed 

serious 

high 

Inadequate 

spacing for TAB tooling under Euterpe 



197 9 pcbtcm PCB 

open 

serious 

high 

Breakaway 

tabs too weak 





1993 arya PCB 

open 

critical 

high 

Ul QPSK amp 

2001 dane PCB 

open 

critical 

medium 

Floating 

leads on A8J1 (Mini DIN) 





2 0 04 pmayer PCB 

open 

serious 

medium 

Chassis 

plane extends inside phone 

barrier 




2007 noel PCB 

open 

critical 

high 

Excessive 

noise on 3.3V power plane. 





2 0 09 noel PCB 

open 

critical 

high 

Excessive 


noise on +5V power plane 
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2010 noel PCB open critical high 

noise on +12V power plane 

2 012 yves PCB open serious medium 

filters near audio/video connectors 

2 014 pmayer PCB analyzed non-criti low 

running through switching supply region 

2 031 woody PCB analyzed critical high 

Hermes connector pin out 

2035 arya PCB analyzed serious high 

203 6 arya PCB analyzed serious high 

2059 rmm PCB closed critical high 

backwards 


Excessive 

Add EMI 

Traces 

Change 

Baluns 

AGC circuit 

Diplexer in 
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To: 


Sent: 


From: 


tbr 

Monday, March 06, 1995 10:54 PM 
Vo' 


Subject: 


clockbias 


Follow Up Flag: Follow up 
Flag Status: Red 

I was updatng my euterpe baseplate with your latest stuff and I 

noticed an unreleased file in the clockbias section 

(clockbias. domains). Is this an oversight, or just something still in 

progress? 


Tim 
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From: 


tbr 


Sent: 

To: 

Cc: 


Monday, March 06, 1995 11:11 PM 

'wampier* 

Vo' 

clockbias problem 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 


I was rebuilding my local euterpe baseplate to pick up torn vo's 

latest stuff, and it failed in regenerating the clocks:sed -e VCBSOFA_MODEL/CBSOFA/g' 
basegen_tmp/cbsofa_mode l_base .pd l \ 
> cbsofa.pdl 

/n/auspex/s 15/tbr/euteipe/proteus/gards/basegen/derive__bounds \ 

cbsofa_model.ly /n/auspex/sl5/tbr/euterpe/compass/vlsi. boo-all > cbsofa_bounds.gsub 
/n/auspex/s 1 5/tbr/euterpe/proteus/clockbias/gsub cbsofabounds.gsub \ 

< /n/auspex/s 15/tbr/euterpe/proteus/clockbias/cbsofa.tdLtemplate > cbsofa.tdl 
/bin/sh: cbsofa.tdl: Permission denied 
gmake: *** [cbsofa.tdl] Error 1 

Seems like we either need a chmod, or an rm before attempting to 
create this: 

tbr@gamorra -/euterpe/clockbias 420 % Is -Is cbsofa.tdl 
3-r~r-r- itbr 2358 Apr 26 1994 cbsofa.tdl 

However, I have in the past rebuilt the clocks several times with no 
problem so do we understand what has changed to start causing this? 


Tim 
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From: 


tbr 


To: 


Subject: 


Sent: 


Tuesday, March 07, 1995 12:14 AM 
'woody' 

instance names 


Follow Up Flag: Follow up 
Flag Status: Red 

I'm looking at the euterpe module schematic, and it looks like all the 
instance names have gone from the main components. I think it is the 
case that you can call out instance names explicilty, rather than let 
GED make arbitrary PnP assignments (which change when you edit the 
schematic). This may be important when we convert to verilog and 
start building signal recording lists for simulation. We'd want the 
instance names fixed, and preferably recognisable. 


Tim 
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From: 


tbr 


To: 


Cc: 

Subject: 


Sent: 


Tuesday, March 07, 1995 12:28 AM 

'woody'; 'dbulfer 1 

'pandora' 

Euterpe module Cerberus clock 


Follow Up Flag: Follow up 
Flag Status: Red 

Should we be making provision on the Euterpe module PCB to be able to 
cut the trace, or include a zero ohm link which could be ommited, in 
the link between scout and sc? We would need this if we wanted to be 
able to reuse the euterpe module in a system which required a Cerberus 
clock from a different source for some reason. An example would be a 
system which needed two euterpe modules. While this is not an issue 
in Pandora itself, which will only have provision for one processor 
module, it may be relevant in some applications. 


Tim 
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From: pmayer (Patricia Mayer) 

Sent: Tuesday, March 07, 1 995 1 :28 AM 

To: tbr* 

Cc: 'pmayer 1 ' 

Subject: PCB layout schedule 

Tim, 

I wanted to revisit our conversation on the PCB layout schedule. 

On Hestia Main, I added 2 weeks to do the Mnemo module in parallel 
to Howard laying out the Euterpe module. This really isn't a great 
significance in my learning if we are to be seperated. Revisit? 

Need to set priority in the following: 

Euterpe 
Mnemo 

Herminator - need for both Pandora and Hestia, Low? 
Back Plane 

PCI Bridge - higher than cronus or PCI Hermes 

Cronus 

PCI Hermes 

Please clarify the priorities and I'll plug in the numbers. 

Thanks 
-Pattie 
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From: woody (Jay Tomlinson) 
Sent: Tuesday, March 07, 1995 9:21 AM 
To: 'tbr (Tim B. Robinson)' 
Subject: instance names 


Tim B. Robinson wrote (on Mon Mar 6): 

I'm looking at the euterpe module schematic, and it looks like all the 
instance names have gone from the main components. T think it is the 
case that you can call out instance names explicilty, rather than let 
GED make arbitrary PnP assignments (which change when you edit the 
schematic). This may be important when we convert to verilog and 
start building signal recording lists for simulation. We'd want the 
instance names fixed, and preferably recognisable. 

Tim 

What you saw before was a 'path' property. I need to find out how to get real 
instance names on there. 

woody 
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From: wampler (Kurt Wampler) 
Sent: Tuesday, March 07, 1 995 9:48 AM 
To: 'tbi- 
Cc: Vo' 

Subject: Re: clockbias problem 
tbr writes: 


>I was rebuilding my local euterpe baseplate to pick up torn vo's 

>latest stuff, and it failed in regenerating the clocks :sed -e , s/CBSOFA_MODEL/CBSOFA/g* 
basegen_tmp/cbsofa_model_base.pdl \ 

> > cbsofa.pdl 

>/n/auspex/sl 5/tbr/euterpe/proteus/gards/basegen/derive_bounds \ 

> cbsofa_model.ly /n/auspex/sl 5/tbr/euterpe/compass/vlsi. boo-all > cbsofa_bounds.gsub 
>/n/auspex/s 1 5/tbr/euterpe/proteus/clockbias/gsub cbsofa_bounds.gsub \ 

> < /n/auspex/sl 5/tbr/euterpe/proteus/clockbias/cbsofa.tdl.template > cbsofa.tdl 
>/bin/sb: cbsofa.tdl: Permission denied 

>gmake: *** [cbsofa.tdl] Error 1 
> 

>Seems like we either need a chmod, or an rm before attempting to 
>create this: 

> 

>tbr@gamorra -Veuterpe/clockbias 420 % Is -Is cbsofa.tdl 

> 3-r-r-r- 1 tbr 2358 Apr 26 1994 cbsofa.tdl 

> 

>However, I have in the past rebuilt the clocks several times with no 
>problem so do we understand what has changed to start causing this? 

Observing the date on this file, I see it's nearly a year old. It used 
to be created by doing a "cp -p" from a template file and then a 
"chmod 644". Since version 1.30 (1 1/8/1994) of clockbias/Makefile.rules 
this file is created by awk instead of cp and should always be owner-write 
by definition. All "cp -p" commands are long gone from this makefile, 
and the current version will never generate owner-readonly files unless 
the user corrupts his/her umask. 

I see a number of obsolete files in /u/tbr/euterpe/clockbias dating back 
to Apr 26 1994, some of which are owner-readonly. 1 think it would be 
safest to blow away this directory in its entirety and start clean. 
Alternatively, a "chmod o+w *" would allow the make to proceed in the 
current directory context. 

-Kurt 
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From: vanthof (vant) 

Sent: Tuesday, March 07, 1995 9:48 AM 

To: 'ken (Ken Hsieh)' 

Cc: Vanthof (Dave Van't Hof)'; "hopper (Mark Hofmann)'; 'geert (Geert Rosseel)' 

Subject: euterpe (Mike Wageman's machine) is not functioning 


Hi Ken, 

Mike Wageman's machine, euterpe, is not feeling very well. We tried to reboot it this 
morning, but the •/' filesystem is full and it won't come back up. I don't know how to 
get it into single user mode to try and clean up ' / 1 . Can you help? 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 ^include <std_disclaim .h> Don't blame 
me, I didn't vote for him! 
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From: vo (Tom Vo) 

Sent: Tuesday, March 07, 1995 12:01 PM 
To: Tim B. Robinson' 
Subject: Re: clockbias 

Tim B. Robinson wrote .... 

> 
> 

>I was updatng my euterpe baseplate with your latest stuff and I 

>noticed an unreleased file in the clockbias section 

>(clockbi as. domains). Is this an oversight, or just something still in 

>progress? 

> 

>Tim 

> 
> 

It can be released . There' were a lot of GARDS activity when I checked in 
the file so I decided to delay the release . Of course , I promptly forgot 
about it . 

I'll need to release the latest baseplate so I'll do both at the same time . 
tvo 
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Subject: 


Sent: 

To: 

Cc: 


From: 


ken (Ken Hsieh) 

Tuesday, March 07, 1995 12:47 PM 
'mikew' 

'vanthof; 'hopper 1 ; 'geert'; 'tor 1 

Re: euterpe (Mike Wageman's machine) is not functioning 


David told me that euterpe back up on the second reboot. 

However, I found the root disk was making a big noise. I have called AVCOM to order a disk 
to replace it before it crash. We will the disk in the next couple of days. 


> From vanthof Tue Mar 7 07:48:22 1995 

> From: vanthof (vant) 

> Subject: euterpe (Mike Wageman's machine) is not functioning 

> To: ken {Ken Hsieh) 

> Date: Tue, 7 Mar 95 7:48:16 PST 

> Cc; vanthof (Dave Van't Hof ) , hopper (Mark Hofmann) , geert (Geert 
Rosseel) 

> X-Mailer: ELM [version 2.3 PL11] 

> Content -Length: 4 72 


> Hi Ken, 

> Mike Wageman's machine, euterpe, is not feeling very well. We 

> tried to reboot it this morning, but the ' /' filesystem is full and it 

> won't come back up. I don't know how to get it into single user mode 

> to try 
and 

> clean up ' / ' ■ Can you help? 

> Thanks, 

> Dave 

> -- 

> Dave Van't Hof vanthof@microunity.com MicroUnity Systems 
Engineering, Inc. 

> 255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include 
<std_disclaim. h> 

> Don't blame me, I didn't vote for him! 


Ken 


> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Tuesday, March 07, 1995 12:53 PM 
'Ken Hsieh' 

'mikew (Mike Wageman)'; 'hopper (Mark Hofmann)'; 'geert (Geert Rosseel)'; 'tbr (Tim B. 
Robinson)' 

Re: euterpe (Mike Wageman's machine) is not functioning 


Ken Hsieh writes: 


>David told me that euterpe back up on the second reboot . 

>However, I found the root disk was making a big noise. I have called 

>AVCOM to order a disk to replace it before it crash. We will the disk 

>in the next couple of days. 

> 

>Ken 

Thanks for finding this Ken. 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc. 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 
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From: tbr 

Sent: Tuesday, March 07, 1995 3:09 PM 

To: 'wampler (Kurt Wampler)' 

Cc: Vo' 

Subject: Re: clockbias problem 

Follow Up Flag: Follow up 

Flag Status: Red 


Kurt Wampler wrote (on Tue Mar 7): 
tbr writes: 

>I was rebuilding my local euterpe baseplate to pick up torn vo's 

>latest stuff, and it failed in regenerating the clocks:sed -e VCBSOFA_MODEL/CBSOFA/g' 
basegen_tmp/cbsofa_m odel_base .pdl \ 

> > cbsofa.pdl 

>/n/auspex/s 1 5/tbr/euterpe/proteus/gards/basegen/derive_bounds \ 

> cbsofajnodel.ly /n/auspex/sl5/tbr/euterpe/compass/vlsi. boo-all > cbsofa_bounds.gsub 
>/n/auspex/s 1 5/tbr/euterpe/proteus/clockbias/gsub cbsofa_bounds.gsub \ 

> < /n/auspex/s 1 5/tbr/euterpe/proteus/clockbias/cbsofa.tdI.temp!ate > cbsofa.tdl 
>/bin/sh: cbsofa.tdl: Permission denied 

>gmake: *** [cbsofa.tdl] Error 1 
> 

>Seems like we either need a chmod, or an rm before attempting to 
>create this: 

> 

>tbr@gamorra -/euterpe/clockbias 420 % Is -Is cbsofa.tdl 

> 3- r - r ... r -_ \ tbr 2358 Apr 26 1994 cbsofa.tdl 

> 

>However, I have in the past rebuilt the clocks several times with no 
>problem so do we understand what has changed to start causing this? 

Observing the date on this file, I see it's nearly a year old. It used 
to be created by doing a "cp -p" from a template file and then a 
"chmod 644". Since version 1 .30 (1 1/8/1994) of clockbias/Makefile.ruIes 
this file is created by awk instead of cp and should always be owner-write 
by definition. All "cp -p" commands are long gone from this makefile, 
and the current version will never generate owner-readonly files unless 
the user corrupts his/her umask. 

I see a number of obsolete files in /u/tbr/euterpe/clockbias dating back 
to Apr 26 1994, some of which are owner-readonly. I think it would be 
safest to blow away this directory in its entirety and start clean. 
Alternatively, a "chmod o+w *" would allow the make to proceed in the 
current directory context. 

Thanks. After removeing the file it did complete ok. 
Tim 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, March 07, 1995 3:18 PM 

To: Tim B. Robinson' 

Cc: 'mws@microunity.com' 

Subject: Re: warning of avoidable veqn bug 

Tim B. Robinson writes: 
I think if we are specifying fields or busses they oughtta match. 
It's only integers where I think we should infer the width. 
It's safer that way. 

Okay. 
So... 

if one side is a constant, then pad with O's 

if neither side is constant and the widths mismatch, then error out? 

-hopper 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, March 07, 1995 3:22 PM 

To: Tim B. Robinson' 

Cc: 'mws@microun ity.com' 

Subject: Re: warning of avoidable veqn bug 

Tim B. Robinson writes: 


Mark Hofmann wrote (on Tue Mar 7): 

Tim B. Robinson writes: 
I think if we are specifying fields or busses they oughtta match. 
It's only integers where I think we should infer the width. 
It's safer that way. 

Okay. 
So... 

if one side is a constant, then pad with O's 

if neither side is constant and the widths mismatch, then error out? 

Yes, and error out if the constant is too big to fit in the field 
width of the other side. 

Right. 

-hopper 
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From: chip (Potatoe Chip) 

Sent: Tuesday, March 07, 1995 3:32 PM 

To: 'geert' 

Subject: output of euterpe/dcell/.checkoutrc 


Tue Mar 7 13:32:17 PST 1995 (geert Tue, 7 Mar 1995 13:32:03 -0800) euterpe/dcell 
[Release BOM (V18.0) in euterpe/dcell (Tue Mar 7 13:32:17 PST 1995)] 


Dir 

euterpe/dcell 

1 . 5 

. checkoutrc 

1.42 

Makefile 

10 . 4 

auindx , dcell 

1 . 5 

cc . dcell 

3 . 6 

cdio . dcell 

1 .26 

cerberus . dcell 

(1-25) 


1 . 9 

cj .dcell 

14 . 2 

ck f gen. dcell 

1 . 2 

clean- request 

13 . 2 

cp . dcell 

11 . 4 

ctio .dcell 

1.2 

dcelldef s .rt»4 

1 . 5 

dr . dcell 

1 . 2 

drio . dcell 

8 . 8 

es . dcell 

2.20 

gt .dcell 

1.5 

he .dcell 

14 .1 

hz .dcell 

1.8 

if e. dcell 

10 .3 

iorate. dcell 

1.7 

iq. dcell 

2 . 13 

It .dcell 

9.4 

mc . dcell 

10 .6 

mst . dcell 

1.8 

nb. dcell 

13.4 

rg. dcell 

1. 15 

rgxmit. dcell 

11.7 

sr . dcell 

1.19 

uu. dcell 

1.4 

xlu. dcell 


===> running euterpe/dcell/.checkoutrc (Tue Mar 7 13:32:23 PST 1995) <=== gmake list 
dcell. topt subcells 

gmake [1]: Entering directory VN/auspex6/slO/chip/euterpe/dcell ' 
gmake [1] : "list" is up to date, 
gmake [1] : "dcell. topt' is up to date. 

/n/auspex6/sl0/chip/euterpe/tools/bin/m4 cerberus . dcell > cerberus . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/dcell < cerberus. tmp mv cerberus . ly 
. . /compass/dcell/cerberus . ly cd . . /compass/dcell; 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpedcell rm -f cerberus. tmp 
gmake [1]: Leaving directory VN/auspex6/slO/chip/euterpe/dcell ' 
[finished at Tue Mar 7 13:32:28 PST 1995 -- exit status 0] 
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From: chip (Potatoe Chip) 

Sent: Tuesday, March 07, 1995 3:41 PM 

To: 'geeif 

Subject: output of euterpe/baseplate/.checkoutrc 


Tue Mar 7 13:34:00 PST 1995 (geert Tue, 7 Mar 1995 13:33:47 -0800) euterpe/baseplate 
[Release BOM (V22.0) in euterpe/baseplate (Tue Mar 7 13:34:00 PST 1995)] 


Dir 

euterpe/baseplate 

1.9 

. checkoutrc 

1.51 

Makefile 

1.1 

clean_request 

1.4 

clockparms .m4 

3.20 

custom. pif 

(3.19) 


1.8 

ecl_cutout . sgen . m4 

3.2 

f loorplan . pif 

1.45 

f loorplan . sgen . m4 

(1.44) 


5.10 

mos_cutout . sgen . m4 

1.28 

padlist . 1st 

1.5 

padring . sgen . m4 

1.3 

spacetrans . sgen . m4 


===> running euterpe/baseplate/.checkoutrc (Tue Mar 7 13:34:08 PST 1995) <=== [ -d 
/n/auspex6/sl0/chip/euterpe/compass/baseplate ] | | mkdir -p 
/n/auspex6/sl0/chip/euterpe/compass/baseplate 

gmake subcells /n/auspex6/sl0/chip/euterpe/compass/baseplate/padtext . ly 
/n/auspex6/sl0/chip/euterpe/compass/baseplate/baseplate . ly\ 
labels 

gmake [1]: Entering directory - /N/auspex6/sl0/chip/euterpe/baseplate 1 
#cp /n/auspex6/sl0/chip/euterpe/proteus/baseplate/f loorplanparms .m4 
f loorplanparms . m4 

cat /n/auspex6/sl0/chip/euterpe/proteus/baseplate/f loorplanparms .m4 > 
f loorplanparms . m4 

/n/auspex6/sl0/chip/euterpe/tools/bin/m4 -B10 0 0 0 0 -Df loorplan_type=revl 
f loorplan. sgen. m4 \ 

> f loorplan. sgen 
rm -f f loorplanparms .m4 

/n/auspex6/sl0/chip/euterpe/tools/bin/sof agen -v 

/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell < f loorplan. sgen mv f loorplan* . ly 

/n/auspex6/sl0/chip/euterpe/compass/baseplate 

cd /n/auspex6/sl0/chip/euterpe/compass/baseplate; 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase 

gmake [1]: Vn/auspex6/sl0/chip/euterpe/compass/baseplate/padtext • ly 1 is up to date, 
echo • POBS = flatten ( POBS ) ; CPOB - flatten (CPOB) ; delete subcell ( ) ; ' \ 

| /n/auspex6/sl0/chip/euterpe/tools/bin/vlsimm -f- -r f loo rplan_obs true t -v 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell f loorplan > tmp. obstruct mv 
tmp . obstruct /n/auspex6/sl0/chip/euterpe/compass/baseplate/f loorplan_obstruct . ly 
cd /n/auspex6/sl0/chip/euterpe/compass/baseplate; 
/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase 
/n/auspex6/sl0/chip/euterpe/tools/bin/ sof agen -v 

/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell < baseplate . sgen mv baseplate* . ly 

/n/auspex6/sl0/chip/euterpe/compass /baseplate 

cd /n/auspex6/sl0/chip/euterpe/compass/baseplate,- 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase 

gmake [1] : Nothing to be done for "labels'. 

gmake [1] : Leaving directory v /N/auspex6/sl0/chip/euterpe/baseplate 1 
grep -w mobieclium_site 

/n/auspex6/sl0/chip/euterpe/compass/baseplate/baseplate_ecl_logic . ly \ 
| grep "*r" \ 

I awk ' {sum=sum+$9*$10 }END{print sum, "eclatoms" } 1 
480164 eclatoms 
grep -w mosatom_site 
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/n/auspex6/sl0/chip/euterpe/compass/baseplate/baseplate_mos_logic . ly \ 
| grep " R " \ 

I awk ' {sum=sum+$9*$10 }END{print sum, "mosatoms" } 1 
77980 mosatoms 

[ -d /n/auspex6/sl0/chip/euterpe/compass/baseplate ] | | mkdir -p 
/n/auspex6/sl0/chip/euterpe/compass/baseplate 

gmake /n/auspex6/sl0/chip/euterpe/compass/baseplate/stpadtext . ly 
gmake[l]: Entering directory "/N/auspex6/sl0/chip/euterpe/baseplate 1 

graake[l]: v /n/auspex6/sl0/chip/euterpe/compass/baseplate/stpadtext . ly 1 is up to date, 
gmakefl]: Leaving directory VN/auspex6/sl O/chip/euterpe/baseplate 1 
gmake /n/auspex6/sl0/chip/euterpe/compass/baseplate/spacetrans . ly 
gmake [1]: Entering directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 
echo 'OBS3 = flatten (OBS3 ) ; OBS4 = flatten (OBS4 ) ; delete subcell ( ) ; ' \ 

| /n/auspex6/sl0/chip/euterpe/tools/bin/vlsimm -f- -p. -v 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell -r st_vdda_p lanes \ 

baseplate_apwr_only > tmpl 
mv tmpl /n/auspex6/sl0/chip/euterpe/compass/baseplate/st_vdda_planes . ly 
cd /n/auspex6/sl0/chip/euterpe/compass/baseplate; 
/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase 
/n/auspex6/sl0/chip/euterpe/tools/bin/vlsi_stats baseplate -v 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-all \ 

-c sofa jvdd_pad \ 

-c sofa_vss_pad \ 

-c custom_vdda_pad \ 

-c custom_vdde_j?ad \ 

-c custom_vss_pad \ 

-x padsites 
Writing new Compass layout: padsites. ly 
########################### 

# Instance counts by cell # 
########################### 
sof a_vdd_j>ad (239) 
custom_vdde_pad (31) 

sof a_vss_pad (240 ) 
custom_vdda_pad (4) 
custom_vss_pad (32) 

# Sed changes the layout cell name from baseplate to stintpads. 
nawk '{ if |$1~/V/| |$1~/G/| I $1-/A/ | | $1~/E/) print $0;\ 

if ($6 ~ /pad/ ) print $0 }'\ 
padsites . ly\ 

| sed 1 s/padsites/stintpads/ ' \ 

| nawk ' BEGIN { xlate [ " \ " sof a_vdd_j>ad\ "" ] = "stintpadvdd"; 
xlate ["\" sof a_vss_pad\ " "] = " stintpadvss" ; 

xlate ["\"custom_vdda_j>ad\" "] = "stintpadvdda" ; 
xlate [ " \ " custom_ydde_pad\ "" ] = 11 stintpadvdd" ; 

xlate [»\"custom_vss_pad\" »] = "stintpadvss"; fmt»"%s %s %d %d RotO 
\"%s%s\" layout \"\"%s\n"; }; /*R/ { extra= sprint f { " %d %d %d 
%d",$9,$10,$ll, $12) ; } ; /"custom_(vdd| vdda|vdde |vss)_pad"/ { 
padprint=l; if ($5=="Rot0 " ) { x=$3; y=$4; typ=" rotate" ; }else 

if ($5=="Rotl") { x=$3-144 0; y=$4; typ=""; }else if ($5=="Rot2 M ) { 

x=$3-960; y=$4 - 1440 ;typ=" rotate"; }else if ($5== "Rot3 " ) { x=$3; 
y=$4-960; typ=""; }else if ( $5== "MX" ) { x=$3-960; y=$4; 

typ= " rotate " ; }else if ($5== "MXRotl" ) {x=$3-l44 0 ; y=$4-960; typ=""; }else 
if ($5=="MY") { x=$3; y=$4 -144 0 ; typ= "rotate" ; }else 

if ($5=="MYRotl") {x=$3; y=$4; typ= " " ; }else{ x=$3 ; 

y=$4; typ=""; } printf (fmt , $1 , $2 , x, y, xlate [$6] , typ , extra) ; }; 

/"sofa_(vdd|vss)_pad"/ { padprint=l; if ($5=="Rot0 " ) { x=$3+40; y=$4; 
typ- " ! 
"; }else if ($5=="Rotl") 
> stintpads. ly 

mv stintpads . ly /n/auspex6/sl0/chip/euterpe/compass/baseplate/ stintpads . ly 
nawk ■{ if <$l~/#/| |$1-/V/| | $1-/0/ | |$1-/A/| | $1-/E/) print $0;\ 
else if ($6 ~ /vdda/ ) print $0 }'\ 

< /n/auspex6/sl0/chip/euterpe/compass/baseplate/stintpads . ly \ 

| sed ' s/ stintpads/ stintvddapads/ ' > 
/n/auspex6/sl0/chip/euterpe/compass/baseplate/stintvddapads . ly 
echo 'POBS = flatten (FOBS ) ; CPOB = flatten (CPOB) ; delete subcell();' \ 

| /n/auspex6/sl0/chip/euterpe/tools/bin/vlsimm -f- -r stintvddapads_ob struct -v 
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/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell stintvddapads > tmp . obstruct mv 
tmp . obstruct /n/auspex6/ si 0/ chip/ euterpe/ compass /baseplate/ stintvddapads_obstruct . ly 
cd /n/auspex6/sl0/chip/ euterpe/compass/baseplate ; 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase nawk '{ if ($l~/#/ | | $1~/V/ 
| | $1-/0/ | |$1-/A/| |$l~/E/)print $0;\ 

else if ($6 !~ /vdda/ ) print $0 }'\ 

< /n/auspex6/sl0/chip/euterpe/compass/baseplate/stintpads . ly \ 

| sed 1 s/stintpads/stintnonvddapads/ 1 > 
/n/auspex6/sl0/chip/euterpe/corapass/baseplate/stintnonvddapads . ly 
echo 'POBS = flatten { POBS ) ; CPOB = flatten(CPOB) ; delete subcell ( ) ; 1 \ 

j /n/auspex6/sl0/chip/euterpe/tools/bin/vlsimm -f- -r stintnonvddapads_obstruct -v 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell stintnonvddapads > tmp . obstruct mv 
tmp . obstruct /n/auspex6 /si 0 /chip/ euterpe /compass /baseplate/ stintnonvddapads_obst rue t . ly 
cd /n/auspex6/sl0/chip/euterpe/compass/baseplate ,- 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase echo 'VS23 = 
frame (grow (nonvdda : flatten (MS 3 ) - flatten (OBS4 ) , -100)\ 

* nonvdda: flatten (0BS1) * nonvdda: flatten (MS2) , \ 
-20+); \ 

delete subcell ( ) ; ' \ 
| /n/auspex6/sl0/chip/euterpe/tools/bin/vlsimm -x -f- -p. -v 
/n/auspex6 / si 0/ chip/ euterpe/compass/vl si .boo-dcell -r st_vdda_connect \ 

-i vdda=stoutvdda_j?adring \ 

-i nonvdda =stoutnonvdda_j?adring \ 

baseplate_apwr_only > tmpl 
mv tmpl /n/auspex6/sl0/chip/euterpe/compass/baseplate/st_vdda_connect . ly 
cd /n/auspex6/sl0/chip/euterpe/compass/baseplate; 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase #cp 
/n/auspex6/sl0/chip/euterpe/proteus/baseplate/chipparms .m4 
chipparms . m4 

cat /n/auspex6/sl0/chip/euterpe/proteus/baseplate/chipparms .m4 > 
chipparms . m4 

/n/auspex6/sl0/chip/euterpe/tools/bin/m4 

/n/auspex6/sl0/chip/euterpe/proteus/baseplate/sharedspacetrans. sgen.m4 > spacetrans . sgen 
rm -f chipparms. m4 /n/auspex6/sl0/chip/euterpe/tools/bin/sof agen -v 

/n/auspexe/slO/chip/euterpe/compass/vlsi .boo-dcell < spacetrans . sgen mv spacetrans* . ly 

/n/auspex6/sl0/chip/euterpe/compass/baseplate 

cd /n/auspex6/ slO/chip/euterpe/compass/baseplate ; 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase 

gmake [1] : Leaving directory VN/auspex6/slO/chip/euterpe./baseplate ' 

cat /n/auspex6/sl O/chip/euterpe/compass/baseplate/ spacetrans . ly | sed 

' ls/spacetrans/euterpep/ ' > tmpl . ly ;\ nawk '{if ($1 == " E " ) {} else { print $0 } } ' 

tmpl.ly > tmp2.1y f - \ cat /n/auspex6/sl0/chip/euterpe/compass/baseplate/sttoplabel . ly >> 

tmp2.1y; \ echo 'L MSI ' >> tmp2 . ly ; \ echo 'N "VSSE" 23940 24060 ' >> tmp2 . ly ; \ echo 

'E' >> tmp2 . ly ; \ mv trap2 . ly /n/auspex6/sl0/chip/euterpe/compass/baseplate/euterpep. ly,- 

\ rm tmpl.ly ; cd /n/auspex6/sl0/chip/euterpe/compass/baseplate ; 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase [ -d 

/n/auspex6/sl0/chip/euterpe/compass/baseplate ] | | mkdir -p 

/n/auspex6/sl0/chip/euterpe/compass/baseplate 

gmake /n/auspex5/ slO /chip/euterpe/compass/baseplate/euterpetop . ly 
gmake[l]: Entering directory VN/auspex6/slO/chip/euterpe/baseplate 1 
#cp /n/auspex6/sl0/chip/euterpe/proteus/baseplate/chipparms .m4 
chipparms .m4 

cat /n/auspex6/sl0/chip/euterpe/proteus/baseplate/chipparms .m4 > 
chipparms .m4 

echo 1 include {chipparms .m4 ) 1 > tmp. sgen. m4 

echo 'units udr =1' >> tmp. sgen. m4 

echo 'default_units = udr' >> tmp. sgen. m4 

echo 'output_cell = euterpetop' >> tmp. sgen. m4 

echo 'technology = MOBIMOS1 1 » tmp. sgen. m4 

#echo 'instance { cell = euterpe origin « (0, 0) cell_orient = 0} 1 

# » tmp. sgen. m4 

# use baseplate for now 

echo 'instance { cell = baseplate origin ■ (0, 0) cell_orient = 0}'\ 
>> tmp. sgen. m4 

echo 'instance { cell = euterpep origin = (0, 0) cell_orient = 0} 1 \ 
>> tmp. sgen. m4 

/n/auspex6/sl0/chip/euterpe/tools/bin/m4 tmp. sgen. m4 > tmp mv tmp euterpetop . sgen rm -f 
tmp. sgen. m4 chipparms. m4 /n/auspex6/sl0/chip/euterpe/tools/bin/sof agen -v 
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/n/auspex6/sl0/chip/euterpe/compass/vlsi.boo-dcell < euterpetop . sgen ; mv euterpetop . ly 
tmpl.ly; nawk '{if ($1 == " E " ) {} else { print $0 } }' tmpl . ly > tmp2.1y; cat 
/n/auspex6/sl0/chip/euterpe/compass/baseplate/sttoplabel . ly >> tmp2.1y; echo ' L MSI 1 >> 
tmp2.1y ; \ echo 'N "VSSE" 23940 24060 ' >> tmp2 . ly ; \ echo ' E 1 >> tmp2 . ly ; \ mv tmp2 . ly 
/n/auspex6/sl0/chip/euterpe/compass/baseplate/euterpetop. ly; 
rm tmpl . ly ; 

cd /n/auspex6/sl0/chip/euterpe/compass/baseplate ; 
/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib -1 euterpebase 
gmake[lj: Leaving directory * /N/auspex6/sl0/chip/euterpe/baseplate ' 
[finished at Tue Mar 7 13:41:04 PST 1995 -- exit status 0] 
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From: billz (Bill Zuravleff) 
Sent: Tuesday, March 07, 1 995 4:04 PM 
To: 'ericm (Eric Murray)'; 'sysadmin' 
Subject: My Files on /n/ghidra/s2 

Eric, 

I'm having problems accessing my working files on 
-billz/euterpe (this is a pointer to /n/ghidra/s2/euterpe ). 
I get messages such as: 

n/ghidra/s2/euterpe: Operation would block. 

or else hanging waiting for a prompt to return. 
Ghidra is back up, right? 

Any idea what's happening. 

Thanks, 

billz 
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From: chip (Potatoe Chip) 

Sent: Tuesday, March 07, 1995 4:04 PM 

To: 'geert' 

Subject: output of euterpe/gards/.checkoutrc 


Tue Mar 7 13:45:40 PST 1995 (geert Tue, 7 Mar 1995 13:45:30 -0800) 
euterpe/gards 

[Release BOM (V4.0) in euterpe/gards (Tue Mar 7 13:45:40 PST 1995)] 

Dir euterpe/gards BOM 4 . 0 

1.8 . checkoutrc 

1.50 Makefile 

1 . 1 sclean- request 

===> running euterpe/gards/.checkoutrc (Tue Mar 7 13:45:44 PST 1995) <=== 
[ -d sofa/ ] | | mkdir -p sofa/ 

/n/auspex6/s!0/chip/euterpe/proteus/gards/basegen/ sofa_exclude baseplate 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell 
Creating work area: 

/N/auspex6/sl0/chip/euterpe/gards/sofa_exclude_95 03 07134 54 8 
Gutting mosatom_site 
Gutting mobieclium_site 
Gutting baseplate_clock_spars 
Building sof a_exclude . ly 

Removing /N/auspex6/sl0/chip/euterpe/gards/sof a_exclude_95030713 454 8 
cp sof aexclude . ly /n/auspex6/sl0/chip/euterpe/compass/baseplate 
mv sofa_exclude . ly sof a/sof a_exclude . ly 

echo ' . /sof a/sof a_model . cdl . abgen . /sof a/sof a .pdl : V > Depend-cdl 
/n/auspex6/sl0/chip/euterpe/tools/bin/vlsimm -M -p ./sofa -v 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell sof a_model >> 
Depend-cdl 

echo ■ ' >> Depend-cdl 

rm -rf Depend-cdl Depend-pdl 

gmake gards 

gmake[l]: Entering directory * /N/auspex6/sl0/chip/euterpe/gards ' 

gmake [1]: fopen: Depend-pdl: No such file or directory 

gmake [1] : fopen: Depend-cdl: No such file or directory 

echo /sof a/sof a_model . cdl . abgen . /sof a/sof a . pdl : V > Depend-cdl 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsimm -M -p ./sofa -v 

/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell sof a_model >> 

Depend-cdl 

echo 11 >> Depend-cdl 

### making dependencies -- Tue Mar 7 13:46:48 PST 1995 
# 

# leafmold cells 
# 

echo 1 LEAF_CELLS = \' > Depend-pdl 

sed ' s/.*/ & \\/ ; $s/\\//' /dev/null >> Depend-pdl 

echo 11 >> Depend-pdl 

for cell in "cat /dev/null * ; do \ 

echo "/$ cell .pdl : \\" >> Depend-pdl; \ 

/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm -M -v 
/n/auspex6/sl0/chip/euterpe/compass/vlsi. boo-dcell $cell >> Depend-pdl; \ 
echo 11 >> Depend-pdl; \ 

done 
# 

# sofa-based custom cells 
# 

echo ' SOFA_CELLS = \ 1 » Depend-pdl 

sed 's/.*/ & \\/; $s/\\//' /dev/null >> Depend-pdl 

echo ' ' >> Depend-pdl 

for cell in "cat /dev/null *" ; do \ 

echo " . /sofa/$cell.pdl : \\" >> Depend-pdl; \ 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsimm -M -v 
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/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell $cell » Depend-pdl; \ 
echo 1 1 >> Depend-pdl; \ 

done 
# 

# full custom cells 
# 

echo ' CUSTOM_CELLS = \ ' » Depend-pdl 

sed 's/.*/ & \\/; $s/\\//' /dev/null » Depend-pdl 

echo ' ' >> Depend-pdl 

for cell in "cat /dev/null " ; do \ 

echo "/$cell.pdl: \\" » Depend-pdl; \ 

/n/auspex6/sl0/chip/euterpe/tools/bin/vlsimm -M -v 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell $cell >> Depend-pdl; \ 

echo 11 >> Depend-pdl; \ 

done 
# 

# dummy cells 
# 

echo ' DCELL_CELLS = V >> Depend-pdl 
sed 's/.*/ & \\/; $s/\\//' /dev/null 
/n/auspex6/sl0/chip/euterpe/dcell/list >> Depend-pdl 
echo 1 ' >> Depend-pdl 

for cell in "cat /dev/null /n/auspex6/sl0/chip/euterpe/dcell/list " ; do \ 

echo " . /dcell/$cell . pdl : 
/n/auspex6/sl0/chip/euterpe/compass/dcell/$cell . ly" >> Depend-pdl; \ 
done 

### finished making dependencies -- Tue Mar 7 13:46:50 PST 1995 
gmake[l]: Leaving directory VN/auspex6/slO/chip/euterpe/gards ' 
gmakefl]: Entering directory VN/auspex6/slO/chip/euterpe/gards ' 
### making dcell/auindx.pdl Tue Mar 7 13:46:52 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/slO/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/ tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x vcca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph auindx) > 
dcell/auindx.pdl . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles3226/auindx. cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:46:59 


Only specified layers will be selected 
database: auindx. gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

Terminated at : 95/03/07 13:46:59 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:47:00 


GDFPDL Version 7.1.23 of January 27, 1994 

Initializing . . . 
Processing layout data . . . 
Reading name list ... 
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Start processing physical types . . . 
Writing logical to physical mapping . . . 
[AUINDX] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF OPH not found. 


One physical type defined. 
%% WARNING: 168 Zero Length Segments. 


Terminated at : 95/03/07 13:47:00 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c auindx -o 
dcell/ /auindx. cutouts 

mv dcel 1/ auindx. pdl .tmp dcell/auindx.pdl 

### finished with dcell/auindx.pdl Tue Mar 7 13:47:03 PST 1995 
### making dcell/cc.pdl -- Tue Mar 7 13:47:03 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME=/n/auspex6/ si 0/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref _0ph_glob=vref _0ph cc) > dcell/cc .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles3342/cc . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:47:11 


Only specified layers will be selected 
database: cc.gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

Terminated at : 95/03/07 13:47:11 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 Create PDL 

Copyright <c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:47:12 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[CC] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI B2P not found. 
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%% WARNING : Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF__0PH not found. 

One physical type defined. 
%% WARNING: 532 Zero Length Segments. 

Terminated at : 95/03/07 13:47:13 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c cc -o dcell//cc . cutouts 
mv dcell/cc .pdl . tmp dcell/ccpdl 

### finished with dcell/ccpdl Tue Mar 7 13:47:16 PST 1995 
### making dcell/cdio .pdl -- Tue Mar 7 13:47:16 PST 19 95 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 
CHlPR00T=/n/auspex6 /slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph cdio) > 
dcell/cdio . pdl . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles3485/cdio . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:47:25 


Only specified layers will be selected 
database: cdio.gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

Terminated at : 95/03/07 13:47:26 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
GARDS GDF PDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:47:27 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[CDIO] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 1076 Zero Length Segments. 
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Terminated at : 95/03/07 13:47:30 

Elapsed CPU time : 0 Hrs 0 Mins 1 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 3 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c cdio -o dcell/ /cdio . cutouts 
mv dcell/cdio.pdl.tmp dcell/cdio .pdl 

### finished with dcell/cdio .pdl -- Tue Mar 7 13:47:33 PST 1995 
### making dcell/cerberus . pdl Tue Mar 7 13:47:33 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp__glob=phim_blp -g vref _Oph_glob=vref _0ph cerberus) > 
dcell/cerberus .pdl . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles3 617/cerberus . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:47:40 


Only specified layers will be selected 
database: cerberus. gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

** WARNING ** GDS file : last block length = 501 

Terminated at : 95/03/07 13:47:40 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:47:41 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping 
[CERBERUS] 


%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 


No pins defined for physical type CERBERUS 

Globalnet VSSC not found. 

Globalnet VDDC not found. 

Globalnet PHI_A2P not found. 

Globalnet PHI_B2P not found. 

Globalnet PHIM_A1P not found. 

Globalnet PHIM_B1P not found. 

Globalnet VREF 0PH not found. 


One physical type defined. 


95/03/07 13:47:41 
0 Hrs 0 Mins 0 Sees 
0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 
/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c cerberus -o 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 
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dcell//cerberus . cutouts 

mv dcel 1/ cerberus .pdl . tmp dcell/cerberus .pdl 

### finished with dcell/cerberus .pdl -- Tue Mar 7 13:47:43 PST 1995 
### making dcell/cj .pdl -- Tue Mar 7 13:47:43 PST 1995 
(cd /n/auspex6 / si 0/ chip/ euterpe /compass /dcel 1; 
HOME=/n/auspex6/slO/chip/euterpe/tools 
CHIPROOT= /n/auspex6 / slO /chip/ euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x vcca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_Oph_glob=vref _0ph c j ) > dcell/cj .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm : vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles374l/c j . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:47:50 


Only specified layers will be selected 
database: cj .gdf will be overwritten 
layer file read 
UOM = 100 0 
METRIC UNITS 

** WARNING ** GDS file : last block length - 573 

Terminated at : 95/03/07 13:47:51 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
GARDS GDF PDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:47:52 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[CJ] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 914 Zero Length Segments. 


Terminated at : 95/03/07 13:47:53 

Elapsed CPU time : 0 Hrs 0 Mins 1 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c cj -o dcell//cj . cutouts 
mv dcell/cj .pdl . tmp dcell/cj .pdl 

### finished with dcell/cj .pdl -- Tue Mar 7 13:47:56 PST 1995 
### making dcell/ck_f gen . pdl Tue Mar 7 13:47:56 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME= /n/auspex6/ si 0/ chip/ euterpe /tools 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 
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/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x vcca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_Oph_glob=vref_Oph ck_fgen) > 
dee ll/ck_f gen.pdl . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory- 
assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles3850/ck_f gen. cif succeeded. 
Root symbol is called ROOT CELL . 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:03 


Only specified layers will be selected 
database: ck_fgen.gdf will be overwritten 
layer file read 
UOM = 10 0 0 
METRIC UNITS 

** WARNING ** GDS file : last block length = 137 

Terminated at : 95/03/07 13:48:03 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:03 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list . . . 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[CK_FGEN] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 5 Zero Length Segments. 


Terminated at : 95/03/07 13:48:03 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/ auspex6 / slO /chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c ck_fgen -o 
dcell//ck_f gen. cutouts 

mv dcell/ck_f gen.pdl . tmp dcell/ck_f gen . pdl 

### finished with dcell/ck_f gen.pdl -- Tue Mar 7 13:48:06 PST 1995 
### making dcell/cp.pdl -- Tue Mar 7 13:48:06 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME=/n/auspex6/sl0/chip/euterpe/tools 
CHIPROOT=/n/auspex6 / si 0 /chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x vcca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phib2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph cp) > dcell/cp .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
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or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles3958/cp. cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design; piddles Started at: 95/03/07 13:48:12 


Only specified layers will be selected 
database: cp.gdf will be overwritten 
layer file read 
UOM = 10 0 0 
METRIC UNITS 


Terminated at : 95/03/07 13:48:12 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.12 3 Create PDL 

Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:13 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[CP] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 44 0 Zero Length Segments. 


Terminated at : 95/03/07 13:48:14 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
CH I PROOT= /n/auspex6/sl0/chip/ eut erpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c cp -o dcell//cp . cutouts 
mv dcell/cp.pdl.tmp dcell/cp.pdl 

### finished with dcell/cp.pdl -- Tue Mar 7 13:48:16 PST 1995 
### making dcell/ctio.pdl -- Tue Mar 7 13:48:16 PST 1995 
(cd /n/auspex6/ slO/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 
CHI PROOT= /n/auspex6 / s 1 0 / chip/eut erpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp__glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph ctio) > 
dcell/ctio .pdl . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles4066/ctio.cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
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Design: piddles Started at: 95/03/07 13:48:23 


Only specified layers will be selected 
database: ctio.gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

** WARNING ** GDS file : last block length = 74 6 

Terminated at : 95/03/07 13:48:23 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:24 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[CTIO] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING : Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 640 Zero Length Segments. 


Terminated at : 95/03/07 13:48:25 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c ctio -o dcell//ctio. cutouts 
mv dcell/ctio .pdl . tmp dcell/ctio .pdl 

### finished with dcell/ctio .pdl -- Tue Mar 7 13:48:27 PST 1995 
### making dcell/dr.pdl Tue Mar 7 13:48:27 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/slO/chip/euterpe/ tools 
CHI PROOT=/n/auspex6/ si 0/chip/euterpe 

/n/auspex6/ si 0/chip/euterpe/ tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph dr) > dcell/dr . pdl . tmp 
/n/auspex6/ si 0/chip/euterpe/ tools /bin/ sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles4174/dr . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:34 


Only specified layers will be selected 
database: dr.gdf will be overwritten 
layer file read 
UOM = 1000 
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METRIC UNITS 

** WARNING ** GDS file : last block length = 987 

Terminated at : 95/03/07 13:48:34 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:35 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list . . . 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[DR] 

%% WARNING: Global net VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF OPH not found. 


One physical type defined. 
%% WARNING: 3 73 Zero Length Segments. 


Terminated at : 95/03/07 13:48:35 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c dr -o dcell//dr. cutouts 
mv dcell/dr .pdl . tmp dcell/dr.pdl 

### finished with dcell/dr.pdl -- Tue Mar 7 13:48:38 PST 1995 
### making dcell/drio . pdl -- Tue Mar 7 13:48:38 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/ compass/dcell ; 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob-phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref _0ph_glob=vref _0ph drio) > 
dcell/drio. pdl . tmp 

/n/auspex6/sl0/chip/euterpe/ tools/bin/ sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles42 82/drio . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:44 


Only specified layers will be selected 
database: drio.gdf will be overwritten 
layer file read 

** WARNING ** GDS file : last block length = 64 9 
UOM = 10 00 
METRIC UNITS 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 


95/03/07 13:48:44 

0 Hrs 0 Mins 0 Sees 

0 Hrs 0 Mins 0 Sees 
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GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:44 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[DRIO] 

%% WARNING: No pins defined for physical type DRIO 

%% WARNING: Globalnet VSSC not found. 

%% WARNING: Globalnet VDDC not found. 

%% WARNING: Globalnet PHI_A2P not found. 

%% WARNING: Globalnet PHI_B2P not found. 

%% WARNING: Globalnet PHIM_A1P not found. 

%% WARNING: Globalnet PHIM_B1P not found. 

%% WARNING: Globalnet VREF OPH not found. 


One physical type defined. 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 


95/03/07 13:48:44 
0 Hrs 0 Mins 0 Sees 
0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 
/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c drio -o dcell//drio . cutouts 
mv dcell/drio.pdl . tmp dcell/drio.pdl 

### finished with dcell/drio.pdl Tue Mar 7 13:48:47 PST 1995 
### making dcell/es.pdl -- Tue Mar 7 13:48:47 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/slO/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/ tools /bin/piddles -r -t mobi2 34 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc-vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_jDlp_glob=phim__blp -g vref_0ph_glob=vref_0ph es) > dcell/es .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles43 90/es . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:56 


Only specified layers will be selected 
database: es.gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 


Terminated at 
Elapsed CPU time 
Elapsed wall clock 
GARDS GDFPDL 7.12 3 


: 95/03/07 13:48:57 
: 0 Hrs 0 Mins 0 Sees 
time : 0 Hrs 0 Mins 1 Sees 
Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:48:58 


GDFPDL Version 7.1.23 of January 27, 1994 
Initializing . . . 
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Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[ES] 

%% WARNING : Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF OPH not found. 


One physical type defined. 
%% WARNING: 2568 Zero Length Segments. 


Terminated at : 95/03/07 13:49:14 

Elapsed CPU time : 0 Hrs 0 Mins 14 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 16 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c es -o dcell//es . cutouts 
mv dcell/es .pdl . tmp dcell/es.pdl 

### finished with dcell/es.pdl -- Tue Mar 7 13:49:17 PST 1995 
### making dcell/gt.pdl -- Tue Mar 7 13:49:18 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref__0ph gt) > dcell/gt .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles4499/gt . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:49:25 


Only specified layers will be selected 
database: gt . gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 


Terminated at : 95/03/07 13:49:26 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
GARDS GDF PDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:49:27 


GDFPDL Version 7.1.23 of January 27, 1994 

Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[GT] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
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%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 


Globalnet PHI_B2P not found. 
Globalnet PHIM_A1P not found. 
Globalnet PHIM_B1P not found. 
Globalnet VREF_0PH not found. 


One physical type defined. 
%% WARNING: 14 3 6 Zero Length Segments. 


Terminated at : 95/03/07 13:49:29 

Elapsed CPU time : 0 Hrs 0 Mins 2 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 2 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/ auspex6 /slO /chip /euterpe /compass/ dee 11 -c gt -o dcell//gt . cutouts 
mv dcell/gt .pdl . tmp dcell/gt.pdl 

### finished with dcell/gt.pdl -- Tue Mar 7 13:49:33 PST 1995 
### making dcell/hc.pdl Tue Mar 7 13:49:33 PST 1995 
(cd /n/auspex6/ si 0/ chip/ euterpe /compass /dcell ; 
HOME=/n/auspex6/sl0/chip/euterpe/tools 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles ~r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc^vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph he) > dcell/hc .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm ; vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles4607/hc . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:49:39 


Only specified layers will be selected 
database: he . gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

** WARNING ** GDS file : last block length = 988 

Terminated at : 95/03/07 13:49:40 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time ; 0 Hrs 0 Mins 1 Sees 
GARDS GDF PDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at : 95/03/07 13:49:40 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing , . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[HC] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF_0PH not found. 


One physical type defined. 
%% WARNING: 24 0 Zero Length Segments. 
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Terminated at : 95/03/07 13:49:41 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c he -o dcell//hc . cutouts 
mv dcell/hc .pdl . tmp dcell/hc.pdl 

### finished with dcell/hc.pdl -- Tue Mar 7 13:49:43 PST 1995 
### making dcell/hz.pdl -- Tue Mar 7 13:49:43 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME=/n/auspex6/slO/chip/euterpe/ tools 
CHIPR00T= /n/auspex6/sl0/chip/euterpe 

/n/auspexe/slO/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim__blp -g vref_0ph_glob=vref_0ph hz) > dcell/hz .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory- 
assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles4715/hz . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:49:49 


Only specified layers will be selected 
database: hz.gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

Terminated at : 95/03/07 13:49:49 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:49:50 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list . . . 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[HZ] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF_0PH not found. 

One physical type defined. 
%% WARNING: 34 Zero Length Segments. 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 


95/03/07 13:49:50 
0 Hrs 0 Mins 0 Sees 
0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 
/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c hz -o dcell//hz . cutouts 
mv dcell/hz .pdl . tmp dcell/hz.pdl 
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### finished with dcell/hz.pdl Tue Mar 7 13:49:52 PST 1995 
### making dcell/if e. pdl Tue Mar 7 13:49:52 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 
CHlPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t raobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x vcca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim blp_glob=phim_blp -g vref_0ph_glob=vref_0ph ife) > dcell/if e . pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles4823 /if e . cif succeeded. 
Root symbol is called ROOTCELL. 
GARBS GDSGDF 7.108 -- GDS to GDP conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:49:58 


Only specified layers will be selected 
database: ife.gdf will be overwritten 
layer file read 
UOM » 1000 
METRIC UNITS 

** WARNING ** GDS file : last block length = 781 

Terminated at : 95/03/07 13:49:58 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at : 95/03/07 13:49:59 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 

Processing layout data . . . 

Reading name list ... 

Start processing physical types . . . 

Writing logical to physical mapping . . . 

[IFE] 

%% WARNING : Globalnet VSSC not found. 

%% WARNING: Globalnet VDDC not found. 

%% WARNING: Globalnet PHI_A2P not found. 

%% WARNING: Globalnet PHI_B2P not found. 

%% WARNING: Globalnet PHIM_A1P not found. 

%% WARNING: Globalnet PHIM_B1P not found. 

%% WARNING: Globalnet VREF_0PH not found. 


One physical type defined. 
%% WARNING: 158 Zero Length Segments. 


Terminated at : 95/03/07 13:49:59 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c ife -o dcell//ife . cutouts 
mv dcell/if e .pdl . tmp dcell/if e . pdl 

### finished with dcell/if e . pdl -- Tue Mar 7 13:50:02 PST 1995 
### making dcell/iorate .pdl -- Tue Mar 7 13:50:02 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x vcca -g vssc=vssc -g vddc=vddc -g 
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phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph iorate) > 
dcell/iorate . pdl . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory- 
assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles4 931/iorate . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:50:08 


Only specified layers will be selected 
database: iorate. gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 


Terminated at : 95/03/07 13:50:08 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:50:09 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping , . . 
[IORATE] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 118 Zero Length Segments. 


Terminated at : 95/03/07 13:50:09 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
CH I PROOT= / n / auspex 6 / s 1 0 / chip / eu t e rpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c iorate -o 
dcell/ / iorate . cutouts 

mv dcell/iorate .pdl . tmp dcell/iorate .pdl 

### finished with dcell/iorate .pdl -- Tue Mar 7 13:50:11 PST 1995 
### making dcell/iq.pdl -- Tue Mar 7 13:50:11 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/slO/chip/euterpe/tools 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref__0ph_glob=vref_0ph iq) > dcell/iq.pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 


Exhibit C12 


Page 88 of 643 


Translation of /usr/tmp/piddles5039/iq . cif succeeded. 

Root symbol is called ROOTCELL. 

GARDS GDSGDF 7.108 -- GDS to GDF conversion 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 

Design: piddles Started at: 95/03/07 13:50:18 


Only specified layers will be selected 
database: iq.gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

** WARNING ** GDS file : last block length - 3 00 

Terminated at : 95/03/07 13:50:18 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:50:19 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list . . . 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[IQJ 

%% WARNING: Globalnet VSSC not found. 
%% WARNING : Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 428 Zero Length Segments. 


Terminated at : 95/03/07 13:50:19 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/slQ/chip/euterpe/proteus/gards/basegen/ derive cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c iq -o dcell//iq . cutouts 
mv dcell/iq.pdl . tmp dcell/iq.pdl 

### finished with dcell/iq.pdl -- Tue Mar 7 13:50:22 PST 1995 
### making dcell/lt.pdl -- Tue Mar 7 13:50:22 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph It) > dcell/lt .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles5147/lt . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:50:29 
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Only specified layers will be selected 
database: lt.gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 


Terminated at : 95/03/07 13:50:30 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
GARDS GDFPDL 7.12 3 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:50:31 


GDFPDL Version 7.1.2 3 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[LT] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM__A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF OPH not found. 


One physical type defined. 
%% WARNING: 10 83 Zero Length Segments. 


Terminated at : 95/03/07 13:50:33 

Elapsed CPU time : 0 Hrs 0 Mins 1 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 2 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c It -o dcell//lt . cutouts 
mv dcell/lt .pdl.tmp dcell/lt.pdl 

### finished with dcell/lt.pdl Tue Mar 7 13:50:36 PST 1995 
### making dcell/mc.pdl -- Tue Mar 7 13:50:36 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME= /n/auspex6 /si 0 /chip/ euterpe / tools 
CHlPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph mc) > dcell/mc .pdl . tmp 
/n/auspex6/ si 0/ chip/ euterpe/ tools/bin/ sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles5255/mc . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:50:44 


Only specified layers will be selected 
database: mc . gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

Terminated at : 95/03/07 13:50:44 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 
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Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:50:45 


GDFPDL Version 7.1.23 of January 27, 1994 

Initializing . . . 
Processing layout data . . . 
Reading name list . . . 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[MC] 


%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 


Globalnet VSSC not found. 
Globalnet VDDC not found. 
Globalnet PHI_A2P not found. 
Globalnet PHIJB2P not found. 
Globalnet PHIM_A1P not found. 
Globalnet PHIM_B1P not found. 
Globalnet VREF OPH not found. 


One physical type defined. 
%% WARNING: 952 Zero Length Segments. 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 


95/03/07 13:50:47 
0 Hrs 0 Mins 1 Sees 
0 Hrs 0 Mins 2 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 
/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c me -o dcell//mc . cutouts 
mv dcell/mc.pdl . tmp dcell/mc.pdl 

### finished with dcell/mc.pdl -- Tue Mar 7 13:50:50 PST 1995 
### making dcell/mst .pdl -- Tue Mar 7 13:50:50 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME=/n/auspex6/slO/chip/euterpe/tools 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph mst) > dcell/mst .pdl . tmp 
/n/auspex6/ si 0/chip/euterpe/ tools/bin/ sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles5363/mst . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright <c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:50:56 

Only specified layers will be selected 
database: mst.gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

** WARNING ** GDS file : last block length = 270 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 


95/03/07 13:50:56 
0 Hrs 0 Mins 0 Sees 
0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:50:57 


GDFPDL Version 7.1.2 3 of January 27, 19 94 
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Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[MST] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM__B1P not found. 
%% WARNING: Globalnet VREF_0PH not found. 


One physical type defined. 
%% WARNING: 432 Zero Length Segments. 


Terminated at : 95/03/07 13:50:58 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
CH I PROOT= /n/ auspex6 / s 1 0 / chip / eut erpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c mst -o dcell//mst . cutouts 
mv dcell/mst .pdl . tmp dcell/mst .pdl 

### finished with dcell/mst . pdl Tue Mar 7 13:51:00 PST 1995 
### making dcell/nb.pdl -- Tue Mar 7 13:51:00 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/sl0/chip/euterpe/tools 
CHlPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t raobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph nb) > dcell/nb .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles547l/nb. cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDP conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:51:09 


Only specified layers will be selected 
database: nb.gdf will be overwritten 
layer file read 
UOM ~ 1000 
METRIC UNITS 

** WARNING ** GDS file : last block length = 954 

Terminated at : 95/03/07 13:51:09 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:51:10 


GDFPDL Version 7.1.23 of January 27, 1994 

Initializing . . . 
Processing layout data . . . 
Reading name list . . . 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[NB] 
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Globalnet VSSC not found. 
Globalnet VDDC not found. 
Globalnet PHI_A2P not found. 
Globalnet PHI_B2P not found. 
Globalnet PHIM_A1P not found. 
Globalnet PHIM_B1P not found. 
Globalnet VREF_OPH not found. 

One physical type defined. 
%% WARNING : 1696 Zero Length Segments. 

Terminated at : 95/03/07 13:51:14 

Elapsed CPU time : 0 Hrs 0 Mins 3 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 4 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c nb -o dcell//nb. cutouts 
mv dcell/nb.pdl . tmp dcell/nb.pdl 

### finished with dcell/nb.pdl Tue Mar 7 13:51:18 PST 1995 
### making dcell/rg.pdl -- Tue Mar 7 13:51:18 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell; 
HOME = /n/ auspex6 / s 1 0 / chip / eut er pe / too 1 s 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph rg) > dcell/rg .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles5579/rg . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c> 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:51:28 


%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 


Only specified layers will be selected 
database: rg . gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

** WARNING ** GDS file : last block length = 189 

Terminated at : 95/03/07 13:51:29 

Elapsed CPU time : 0 Hrs 0 Mins 1 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
GARDS GDF PDL 7,123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:51:30 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list . . . 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[RG] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 
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One physical type defined. 
%% WARNING: 2822 Zero Length Segments. 

Terminated at : 95/03/07 13:52:00 

Elapsed CPU time : 0 Hrs 0 Mins 2 9 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 3 0 Sees 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c rg -o dcell//rg. cutouts 
mv dcell/rg.pdl . tmp dcell/rg.pdl 

### finished with dcell/rg.pdl -- Tue Mar 7 13:52:04 PST 1995 
### making dcell/rgxmit .pdl -- Tue Mar 7 13:52:04 PST 1995 
(cd /n/auspex6/ slO/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph rgxmit) > 
dcell/rgxmit .pdl . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles5687/rgxmit . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:52:10 


Only specified layers will be selected 
database: rgxmit. gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 

** WARNING ** GDS file : last block length 


549 


Terminated at : 95/03/07 13:52:10 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:52:11 


GDFPDL Version 7.1.2 3 of January 27, 1994 

Initializing . . . 
Processing layout data . . . 
Reading name list . . . 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[RGXMIT] 

%% WARNING: Globalnet VSSC not found, 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 490 Zero Length Segments. 


Terminated at 
Elapsed CPU time 


95/03/07 13:52:12 

0 Hrs 0 Mins 0 Sees 
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Elapsed wall clock time : 0 Hrs 0 Mins 1 Sees 
CH I PROOT= /n/ auspexS / s 1 0 / chip / eut e rpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c rgxmit -o 
dcell//rgxmit . cutouts 

rav dcell/rgxmit .pdl . tmp dcell/rgxmit .pdl 

### finished with dcell/rgxmit .pdl -- Tue Mar 7 13:52:15 PST 1995 
### making dcell/sr. pdl -- Tue Mar 7 13:52:15 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/slO/chip/euterpe/ tools 
CH I PROOT= /n/ auspex6 / s 1 0 / chip / eut e rpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x veca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob==phim_blp -g vref Oph_glob=vref_0ph sr) > dcell/sr .pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles5795/sr . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 13:52:22 


Only specified layers will be selected 
database: sr.gdf will be overwritten 
layer file read 
UOM = 10 0 0 
METRIC UNITS 

** WARNING ** GDS file : last block length = 706 

Terminated at : 95/03/07 13:52:22 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.12 3 Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:52:23 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[SR] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING : Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF_0PH not found. 

One physical type defined. 
%% WARNING: 728 Zero Length Segments. 


Terminated at : 95/03/07 13:52:23 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/ auspex6/ si 0 /chip/ euterpe 

/n/auspex6/ slO/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c sr -o dcell//sr . cutouts 
mv dcell/sr .pdl . tmp dcell/sr. pdl 

### finished with dcell/sr. pdl Tue Mar 7 13:52:26 PST 1995 
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### making dcell/uu.pdl -- Tue Mar 7 13:52:26 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/compass/dcell ; 
HOME=/n/auspex6/slO/chip/euterpe/ tools 
CHlPROOT=/n/auspex6/sl0/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x vcca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_Oph_glob=vref_Oph uu) > dcell/uu.pdl . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles5903/uu. cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at : 95/03/07 13:52:33 


Only specified layers will be selected 
database: uu.gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 


95/03/07 13:52:33 
0 Hrs 0 Mins 0 Sees 
0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:52:34 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
tuu] 

%% WARNING: Globalnet VSSC not found. 
%% WARNING: Globalnet VDDC not found. 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found, 
%% WARNING: Globalnet PHIM_A1P not found. 
%% WARNING: Globalnet PHIM_B1P not found. 
%% WARNING: Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 579 Zero Length Segments. 


Terminated at : 95/03/07 13:52:34 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c uu -o dcell//uu . cutouts 
mv dcell/uu.pdl . tmp dcell/uu.pdl 

### finished with dcell/uu.pdl -- Tue Mar 7 13:52:37 PST 1995 
### making dcell/xlu.pdl -- Tue Mar 7 13:52:37 PST 1995 
(cd /n/auspex6/sl0/chip/euterpe/ compass/dcell ; 
HOME=/n/auspex6/slO/chip/euterpe/ tools 
CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/tools/bin/piddles -r -t mobi234 -c vial2 -x 
vsse -x vdde -x vdda -x vssa -x vcca -g vssc=vssc -g vddc=vddc -g 
phi_a2p_glob=phi_a2p -g phi_b2p_glob=phi_b2p -g phim_alp_glob=phim_alp -g 
phim_blp_glob=phim_blp -g vref_0ph_glob=vref_0ph xlu) > dcell/xlu.pdl. tmp 
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/n/auspex6/sl0/chip/euterpe/tools/bin/sun4/vlsimm: vlsi.boo: No such file 
or directory 

assuming all cells in current directory 
Cannot open vlsi.boo. Assuming all cells are local. 
Translation of /usr/tmp/piddles601l/xlu.cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 13:52:45 


Only specified layers will be selected 
database: xlu . gdf will be overwritten 
layer file read 
UOM = 1000 
METRIC UNITS 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 


95/03/07 13:52:46 
0 Hrs 0 Mins 0 Sees 
0 Hrs 0 Mins 1 Sees 
GARDS GDFPDL 7 . 123 - - Create PDL 

Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at : 95/03/07 13:52:47 


GDFPDL Version 7.1.23 of January 27, 1994 

Initializing . . . 
Processing layout data . . . 
Reading name list ... 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[XLU] 


%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 
%% WARNING 


Globalnet VSSC not found. 
Globalnet VDDC not found. 
Globalnet PHI_A2P not found. 
Globalnet PHI_B2P not found. 
Globalnet PHIM_A1P not found. 
Globalnet PHIM_B1P not found. 
Globalnet VREF 0PH not found. 


One physical type defined. 
%% WARNING: 14 34 Zero Length Segments. 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 


95/03/07 13:52:50 
0 Hrs 0 Mins 3 Sees 
0 Hrs 0 Mins 3 Sees 
CHIPROOT=/n/auspex6/slO/chip/euterpe 
/n/auspex6/ si 0 /chip/ euterpe/proteus/gards/basegen/derive_cutouts -p 
/n/auspex6/sl0/chip/euterpe/compass/dcell -c xlu -o dcell/ /xlu . cutouts 
mv dcell/xlu.pdl. tmp dcell/xlu.pdl 

### finished with dcell/xlu.pdl -- Tue Mar 7 13:52:54 PST 1995 
[ -d sofa/ ] | S mkdir -p sofa/ 

(echo 'CELL : E1X1; • ; echo ' CELL : M1X1; ' ; \ 

(cd /n/auspex6/sl0/chip/euterpe/proteus/gards/leaf ; cat *.pdl); \ 
(cd /n/auspex6/sl0/chip/euterpe/proteus/gards/sofa; cat *.pdl)j \ 
grep -i 1 CELL. *:.* [0-9] X [0-9] 1 \ 

sed -e 's/.*[: ] \ ( . * [0- 9] [0- 9] * [Xx] [0-9] [0-9] *\) ; . */\l/g' \ 
sort -tX +0n +ln | uniq > . /sofa/prof iles . txt 
sort -u /n/auspex6/sl0/chip/euterpe/dcell/list 
/n/auspex6/sl0/chip/euterpe/proteus/dcell/list 
/n/auspex6/sl0/chip/euterpe/proteus/dcell/custom-list \ 

| sed 's/$/ L I (METAL2 , METAL3 , METAL4 ) / 1 > leaf . sel 
[ -d sofa/ ] j | mkdir -p sofa/ 

PATH= . : /u/chip/tools/bin: /usr/local/bin: /usr/ucb : /usr/bin: /bin: /n/auspex6/ 
slO/chip/euterpe/tools/sl/bin HOME=/n/auspex6/slO/chip/euterpe/ tools \ 

/n/auspex6/ slO/chip/euterpe/proteus/gards/basegen/f reepos_cdls 
. /sofa/sofamodel . ly leaf . sel 
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/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell 
Tue Mar 7 13:58:29 PST 1995 

Initializing work area: /N/auspex6/sl0/chip/euterpe/gards/f reepos_tmp 
****************************************** 

Abstracting free cell positions with abgen 
****************************************** 

Building cell tree. 


Cells read: 

Instances : 

* WARNING* 

* WARNING* 

♦WARNING* 

♦WARNING* 

♦WARNING* 

♦WARNING* 

♦WARNING* 

♦WARNING* 

♦WARNING* 

♦WARNING* 

♦WARNING^ 

♦WARNING^ 

♦WARNING* 

♦WARNING* 

♦ WARNING ♦ 

♦WARNING* 

♦WARNING* 

♦WARNING* 

* WARNING ♦ 

♦WARNING* 

♦WARNING* 

♦WARNING* 

♦WARNING* 

♦WARNING^ 

♦ WARNING ♦ 

♦WARNING^ 

♦WARNING* 

♦WARNING* 

* WARNING ♦ 

♦WARNING* 

♦WARNING ♦ 

♦WARNING* 

♦WARNING* 

♦WARNING ♦ 

♦WARNING^ 

♦WARNING^ 

♦WARNING^ 

♦WARNING ♦ 

♦WARNING^ 

♦WARNING^ 

♦WARNING^ 

♦WARNING ♦ 

♦WARNING^ 

♦WARNING^ 

♦WARNING* 

♦WARNING^ 

♦WARNING^ 

♦WARNING* 

♦WARNING* 

♦ WARNING ♦ 

♦WARNING* 

♦WARNING^ 

♦WARNING* 

♦WARNING* 


142 
945702 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 


"aatop" not in tree 
"addnf " not in tree 
"addnfds" not in tree 
"afbbtop" not in tree 
"afdds" not in tree 
"aftop" not in tree 
"audioadc" not in tree 
"audiodac" not in tree 
"bbagc" not in tree 
"bgiref" not in tree 
"cahalf" not in tree 
" capcalib" not in tree 
" cerpokgen3 " not in tree 
"ck_ckfgentop" not in tree 
"clio" not in tree 
"clknob" not in tree 
"clrepeat" not in tree 
"cplltop" not in tree 
"eplltop" not in tree 
" iobytem" not in tree 
"loquad" not in tree 
"mb" not in tree 
"pl_mne H not in tree 
"pll" not in tree 
"ratop" not in tree 
"rdactop" not in tree 
"rfadc" not in tree 
"rfdac" not in tree 
"rfdacl" not in tree 
"rfdac2" not in tree 
"rfdac 3" not in tree 
"rffilt" not in tree 
"rfmix" not in tree 
"rfmux" not in tree 
"rrfamp" not in tree 
"rrfmix" not in tree 
"rvpplpS" not in tree 
"rxibias" not in tree 
"rxiqmix4" not in tree 
"rxlnamx" not in tree 
"rxtop" not in tree 
"rxucmix" not in tree 
"sy501oad" not in tree 
"sypll" not in tree 
"tag" not in tree 
"testbb" not in tree 
"trfamp" not in tree 
"ttle2ttl" not in tree 
"vdactop" not in tree 
"voltref" not in tree 
"vr0p5vpp" not in tree 
"vr0p5vss" not in tree 
"vr0p8vpp" not in tree 
"vrlpSvss" not in tree 


Exploding. . . 

**************************************************** 
♦WARNING^ - the following cells contain metal 

geometry but have not been abstracted! 
**************************************************** 
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sof a_j)ins 

mob i e c 1 ium_noxi s t o r s 

hemecl_lrs 

mast_shields 

gaf f_bias 

ecl_pc_bus 

hemec l__p c_bus_t s 

hem e c l_jp c_bu s_b s 

ecl_pc_busm 

gaf f _spar_bias 

hemmospar_ts 

hemmo s_bs 

ifl 

hem if l_ts 
hem if l_bs 

ifr 

hem if r_ts 
hem if r_bs 
sof a_vss_pad 
sof a_vdd_jjad 
hemmos_ts 
hemmos_lrs 
hemmo s_ul 
hemmo s_p lugu 
hemmos_ll 
hemmo s_p lug 1 
padtl 
padtr 
padbr 
padbl 

padf atwire 

padvss 

padhib 

padvdd 

padvdda 

padttl 

padrf 

tnv sof a_model . cdl . abgen . /sof a/sof a_model . cdl . abgen 

echo 1 ■ >>. /sof a/sof a_model . cdl . abgen 

echo 1 (* Cell: CGCLOCKBIAS *)' >>. /sof a/sof a_model . cdl . abgen 

echo ' CELLNAME : CGCLOCKBIAS; 1 ». /sof a/sof a_model . cdl . abgen 

echo 1 SIZE: 24000.24000;' >>. /sof a/sof a_model . cdl .abgen 

echo 1 OFFSET : 0.0;' >>. /sof a/sof a_model . cdl . abgen 

echo 'POS: 0.0+0;' >>. /sof a/sof a_model . cdl . abgen 

echo ' ENDCELL ; ' >> . /sof a/sof a_model . cdl . abgen 

sed -e ' s/4772000\ . 264000 ; /4772000 . 192000;/ 1 \ 

-e 's/3180000\. 3576000,-/912000. 3576000;/' \ 
. /sofa/ sof a_model . cdl . abgen > . /sof a/sof a_model . cdl . abgen. tmp 
mv ./sof a/ sof a model . cdl . abgen . tmp . /sof a/sof amodel . cdl . abgen 
[ -d sofa/ ] [J mkdir -p sofa/ 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_bounds 

. /sof a/sof a_model . ly /n/auspex6/ slO/chip/euterpe/compass/vlsi . boo-dcell 

> . /sof a/sof a_bounds . gsub 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/gsub 
. /sof a/sof a_bounds . gsub 

</n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/sof acdl . c . template \ 

> . /sof a/sof acdl . c 
cc -g . /sof a/sof acdl . c -o . /sof a/sof acdl 

. /sof a/sof acdl . /sof a/prof iles . txt . /sof a/sof a_exclude . ly 
/n/auspex6/sl0/chip/euterpe/proteus/gards/sof a | \ 

sed -e 1 / *END_OF_FILE ; /d 1 > sof a/sof a. cdl 
cat ./sofa/sofa_model.cdl.abgen >> sof a/sof a. cdl 
/usr/5bin/echo ' \nEND_OF_FILE; ' >> sof a/sof a . cdl 
[ -d sofa/ ] | | mkdir -p sofa/ 

PATH= . : /u/chip/ tools/bin: /usr /local/bin : /usr/ucb: /usr/bin: /bin: /n/auspex6/ 
slO/chip/euterpe/tools/sl/bin H0ME=/n/auspex6/ si 0/ chip/ euterpe/ tools \ 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/basegen \ 

. /sof a/sof a_model . ly 
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/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/f lat . sel 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell 
Tue Mar 7 13:59:50 PST 1995 

Initializing work area: /N/auspex6/sl0/chip/euterpe/gards/basegen_tmp 
**************************************** 

Running abgen. . . 

**************************************** 
Building cell tree. . . 


142 
945702 

Selected cell "ifcl" not in tree 
Selected cell "mobieclium_probe" not in tree 
Selected cell "padmobi" not in tree 
"padtest" not in tree 
"padtestvdda" not in tree 
"padtestvddbot " not in tree 
"padtestvddlef t" not in tree 
Selected cell "padtestvddright " not in tree 
Selected cell "padtestvddtop" not in tree 
"padtestvssbot" not in tree 
"padtestvsslef t " not in tree 
Selected cell "padtestvssright" not in tree 
Selected cell "padtestvsstop" not in tree 
"powerwaf f le_e" not in tree 
"testmodcl" not in tree 
"noisediff" not in tree 
Selected cell "hepharn" not in tree 
Selected cell "horm4con n not in tree 
verconm4" not in tree 
horlink" not in tree 
vrrvbus" not in tree 
avddpad_m5" not in tree 
avsspad_m5" not in tree 
pllwl" not in tree 
pllw2" not in tree 
som_m3 " not in tree 
som m4" not in tree 


Selected cell 
Selected cell 
Selected cell 
Selected cell 


Selected cell 
Selected cell 


Selected cell 
Selected cell 
Selected cell 


Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 
Selected cell 


Cells read: 
Instances : 
* WARNING* 
* WARNING* 
* WARNING* 
♦WARNING* 
* WARNING* 
* WARNING* 
* WARNING* 
* WARNING* 
♦WARNING* 
♦WARNING* 
* WARNING* 
♦WARNING* 
*WARNING* 
★WARNING* 
♦WARNING* 
♦WARNING* 
♦WARNING* 
* WARNING* 
♦WARNING* 
* WARNING* 
* WARNING* 
♦WARNING* 
*WARNING* 
♦WARNING* 
♦WARNING* 
♦WARNING* 
♦WARNING* 
Exploding. . . 

**************************************************** 
♦WARNING* - the following cells contain metal 

geometry but have not been abstracted! 
**************************************************** 

ck_f gen 
cp 

cdio 
iq 
cj 
It 

ctio 

iorate 

nb 

gt 

cc 

uu 

he 

dr 

hz 

ife 

sr 

auindx 

rgxmit 

mst 

xlu 

mc 

rg 

es 

cerberus 
cli 
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cache 

pl_euh 

pl_eus 

iobyte 

bgproca2d 

tsensa 

bgknobgen 

bellybutt 

bg3stack 

cerpokgen 

ctag 

gtlb 

cr 

ttle2teu 

ledkbdip 

ledsegdrv 

bgbbcstm 

ttl3vnew 

leddigdrv 

mast_shields 

gaf fjbias 

ecl_pc_bus 

hemecl_pc_bus_ts 

heme c l_jp c_bus_b s 

ecl_pc_busm 

gaf f spar_bias 

hemmospar_t s 

ifl 

hem if l_ts 
hemif l_bs 
ifr 

hemif r_ts 
hemif rbs 
sofa_vss_pad 
so f a_vdd_p a d 
**************************************** 

Abstracting flat cells for chip base... 
**************************************** 

Cell: hemecl_lrs 

Cell: hemmo s__b s 

Cell: hemmo s__l 1 

Cell: hemmo s_l r s 

Cell: hemmo s_p lug 1 

Cell: hemmo s_p lugu 

Cell: hemmo s__ts 

Cell: hemmos_ul 

Cell: mobieclium_noxistors 

Cell: sofa_pins 

Cell: padhib 

Cell: padfatwire 

Cell: padvdd 

Cell: padvss 

Cell: padvdda 

Cell: padrf 

Cell: padttl 

Cell: padbl 

Cell: padbr 

Cell: padtl 

Cell: padtr 

**************************************** 
Compiling base cell: sofa_model 
**************************************** 

Protecting targets 

Simplifying metal layers 

Compiling target contexts 
Translation of /usr/tmp/piddles6840/sof a_model_targets . cif succeeded. 
Root symbol is called ROOTCELL. 
GARDS GDSGDF 7.108 -- GDS to GDF conversion 
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Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 14:03:11 


Only specified layers will be selected 
database: sof a_model_targets .gdf will be overwritten 
layer file read 
UOM = 10 00 
METRIC UNITS 

** WARNING ** GDS file : last block length = 512 

Terminated at : 95/03/07 14:03:11 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.123 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 14:03:12 


GDFPDL Version 7.1.23 of January 27, 1994 

Initializing . . . 

Processing layout data . . . 

Reading name list ... 

Start processing physical types . . . 

Writing logical to physical mapping . . . 

[ SOFA_MODEL_TARGETS ] 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%% WARNING: Globalnet VREF_0PH not found. 

One physical type defined. 
%% WARNING: 124 Zero Length Segments. 

Terminated at : 95/03/07 14:03:12 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 

Compiling routing obstructions 
**************************************** 

/N/auspex6/ slO/chip/euterpe/ gards/basegen_tmp 

44 -rw-r--r-- 1 chip 4417 6 Mar 7 14:03 sof a_model_base .pdl 

0 -rw-r--r-- 1 chip 0 Mar 7 14:03 sof a_model_leaf cells . cdl 

**************************************** 

Tue Mar 7 14:03:16 PST 1995 

sed 1 s/SOFA_MODEL/SOFA/ ' basegen_tmp/sof a_model_base .pdl > sof a/sofa .pdl 
if [ -f 

/n/auspex6/sl0/chip/euterpe/compass/baseplate/baseplate_clock_spars . ly ] ; 

\ 

then \ 

cd ./sofa,- \ 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/sof a_captiles 
baseplate_clock_spars /n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-dcell ; 
\ 

fi 

Creating work area: 

/N/auspex6/sl0/chip/euterpe/gards/sof a/sof a_captiles_9503 0714 0317 

###Abstracting sof ajpadtiles . ly . . . 

###Abstracting sof a_spartiles . ly ... 

###Writing sof a_captiles . coef f ... 

###Creating sof a_padtiles .obs ... 

###Creating sof a_pads_spars . obs ... 

Removing /N/auspex6/sl0/chip/euterpe/gards/sof a/sof a_captiles_9503 0714 0317 
[ -d sofa/ ] | | mkdir -p sofa/ 

/n/auspex6/ slO/chip/euterpe/proteus/gards/basegen/gsub \ 

. / sof a/sof a_bounds . gsub 
</n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/sof a. tdl . template 
>sofa/sofa. tdl 

gmake[l]: Leaving directory "/N/auspex6/sl0/chip/euterpe/gards ' 
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[finished at Tue Mar 7 14:03:31 PST 1995 -- exit status 0] 


i 

! 
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From: chip (Potatoe Chip) 

Sent: Tuesday, March 07, 1995 4:28 PM 

To: 'geert' 

Subject: output of euterpe/clockbias/. checkoutrc 

Tue Mar 7 14:03:55 PST 1995 (geert Tue, 7 Mar 1995 13:47:38 -0800) euterpe/clockbias 
[Release BOM (VI. 0) in euterpe/clockbias (Tue Mar 7 14:03:55 PST 1995)] 

Dir euterpe/clockbias BOM 7.0 

1.8 . checkoutrc 

1.28 Makefile 

6.1 clockbias. domains (No) 


===> running euterpe/clockbias/ . checkoutrc (Tue Mar 7 14:04:02 PST 1995) 
/n/auspex6 /slO/ chip /euterpe/proteus/ clockbias /cbsof a_exclude 
baseplate_clock_spars /n/auspex6/sl0/chip/euterpe/compass/vlsi .boo- all 
baseplate 

Creating work area: 

/N/auspex6/sl0/chip/euterpe/clockbias/cbsof a_exclude_9503 0714 04 07 

/N/auspex6/sl0/chip/euterpe/clockbias/cbsofa_exclude_9503 07l4 04 07 

/N/auspex6/sl0/chip/euterpe/clockbias 

Gutting mosatom_site 

Gutting mobieclium_site 

Gutting ifm 

Gutting ifl & ifr 

Masking clock tracks 

Building cbsof a_exclude . ly 

Gutting ecl_pc_busm 

Gutting gaf f_spar_bias 

Building cbsof a_mask . ly 

Removing /N/auspex6/sl0/chip/euterpe/clockbias/cbsofa_exclude_9503 07140407 
returning context to: /N/auspex6/sl0/chip/euterpe/clockbias 
/n/auspex6/sl0/chip/euterpe/proteus/clockbias/cbsof a_model 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-all 
Building cell tree. . . 


Cells read: 2 3 

Instances: 9 
Exploding. . . 
Writing . ly file... 

cp cbsof a_model . ly cbsof a_mask. ly cbsof a_exclude . ly 
/n/auspex6/sl0/chip/euterpe/compass/baseplate 
HOME=/n/auspex6/slO/chip/euterpe/ tools 

LM_LlCENSE_FILE=/n/auspex6/sl0/chip/euterpe/tools/sl/license/license .dat 
DISPLAY=thoas : 0 SL_TOTAL_DURATION=5 0 0 CHIPROOT=/n/auspex6 / slO /chip/euterpe 
/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/basegen \ 

cbsof a_model . ly /n/auspex6/sl0/chip/euterpe/proteus/clockbias/cbsof a . sel 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-all 
Tue Mar 7 14:05:04 PST 1995 

Initializing work area: /N/auspex6/sl0/chip/euterpe/clockbias/basegen_tmp 

**************************************** 

Running abgen. . . 

**************************************** 
Building cell tree. . . 
Cells read: 26 
Instances: 107586 
Exploding. . . 

**************************************** 
Abstracting flat cells for chip base... 
**************************************** 

Cell : aofa^vssjpad 

Cell : sof a_vdd_pad 

Cell: ifl 

Cell: ifm 
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Cell: ifr 

Cell : ecljpc_bus 

Cell : ecl_pc_busm 

Cell: hemecl_pc_bus_ts 

Cell: hemecl_pc_bus_bs 

Cell : mast_shields 

Cell : gaf f _bias 

Cell : gaf f _spar_bias 

Cell : hemecl_lrs 

Ce 1 1 : hemmospar_t s 

Cell: hemmos_bs 

Cell: hemifl_ts 

Cell: hemi f r_t s 

Cell: hemifl_bs 

Cell : hemif r_bs 

Cell : cbsof a_mask 

**************************************** 

Compiling base cell: cbsof a_model 
**************************************** 

Protecting targets 

Simplifying metal layers 

Compiling target contexts 
Translation of /usr/tmp/piddles855 9/cbsofa_model_targets . cif succeeded. 
Root symbol is called ROOTCELL. 

GARDS GDSGDF 7.108 GDS to GDF conversion Copyright (c) 1995 SILVAR-LISCO . All rights 
reserved. 

Design: piddles Started at: 95/03/07 14:07:04 


Only specified layers will be selected 
database: cbsof a_model_targets . gdf will be overwritten layer file read UOM = 10 0 0 METRIC 

UNITS 

Terminated at : 95/03/07 14:07:04 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.12 3 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: piddles Started at: 95/03/07 14:07:05 


GDFPDL Version 7.1.23 of January 27, 1994 

Initializing . . . 

Processing layout data . . . 

Reading name list ... 

Start processing physical types . . . 

Writing logical to physical mapping . . . 

[ CB SO FA_MODE L_TARGETS ] 
%% WARNING: Globalnet PHI_A2P not found. 
%% WARNING: Globalnet PHI_B2P not found. 
%%• WARNING: Globalnet VREF_0PH not found. 

One physical type defined. 
%% WARNING: 45 Zero Length Segments. 

Terminated at : 95/03/07 14:07:05 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 

Compiling routing obstructions 
**************************************** 
/N/auspex6/sl0/chip/euterpe/clockbias/basegen_tmp 

56 -rw-r--r-- 1 chip 56999 Mar 7 14:07 cbsof a_model_base . pdl 

0 -rw-r--r- 1 chip 0 Mar 7 14:07 

cbsof a_model_leaf cells . cdl 
**************************************** 

Tue Mar 7 14:07:16 PST 1995 

sed -e ' s/CBSOFA_MODEL/CBSOFA/g' basegen_tmp/cbsof a_model_base .pdl \ 
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> cbsofa.pdl 

/n/auspex6/sl0/chip/euterpe/proteus/gards/basegen/derive_bounds \ 

cbsof a_model . ly /n/auspex6/sl0/chip/euterpe/compass/vlsi .boo- all > cbsof a^bounds . gsub 
/n/auspex6/slQ/chip/euterpe/proteus/clockbias/gsub cbsof abounds . gsub \ 

< /n/auspex6/sl0/chip/euterpe/proteus/clockbias/cbsofa. tdl. template > cbsof a. tdl 
/n/auspex6/sl0/chip/euterpe/proteus/clockbias/make_cbmacros 
/n/auspex6/sl0/chip/euterpe/proteus/gards/sofa cge 

/n/auspex6/sl0/chip/euterpe/proteus/clockbias/gsub cbsof ajsounds . gsub \ 

< /n/auspex6/sl0/chip/euterpe/proteus/clockbias/cbsofacdl . c . template > cbsof acdl.c gcc - 
g cbsofacdl.c -o cbsofacdl /n/auspex6/sl0/chip/euterpe/proteus/clockbias/get_prof lies 
cbmacros.pdl > profiles.txt ./cbsofacdl profiles.txt cbsof a_exclude . ly > cbsofa.cdl cat 
/n/auspex6/sl0/chip/euterpe/proteus/clockbias/cge .gsub 

cbsof a_bounds . gsub > autospar . gsub 

/n/auspex6/sl0/chip/euterpe/proteus/clockbias/gsub autospar . gsub 
</n/auspex6/sl0/chip/euterpe/proteus/clockbias/autospar . c . template \ 

> autospar. c 
rra autospar , gsub 

gcc -g -0 -I/n/auspex6/sl0/chip/euterpe/tools/ include autospar. c -o autospar ./autospar 

mobieclium_site mast_shields gaff_bias \ 

/n/auspex6/sl0/chip/euterpe/compass/baseplate/baseplate_clock_spars . ly \ 
/n/auspex6/sl0/chip/euterpe/compass/baseplate/baseplate_ecl_logic . ly n5 

s6 n3 

Reading arrays of mobieclium_site cells in 

/n/auspex6/sl0/chip/euterpe/compass/baseplate/baseplate_clock_spars . ly : 
32930 cells 

Reading arrays of mast_shields cells in 

/n/auspex6/sl0/chip/euterpe/compass/baseplate/baseplate_clock_spars . ly : 
2079 cells 

Reading arrays of gaff_bias cells in 

/n/auspex6/sl0/chip/ euterpe/compass/baseplate/baseplate_clock_spars . ly : 
2079 cells 

Reading arrays of mobieclium site cells in 

/n/auspex6/sl0/chip/euterpe/compass/baseplate/baseplate_ecl_logic . ly : 
480164 cells 

Building eclsofa bitmap. . . 

MAST from (158,539) to (4692,539) 

GAFF from (158,536) to (4692,536) 


SPAR ( 0 ) 





north: 

at 

(350,542) , 

length : 

62 eclatoms 

south : 

at 

(350,536) , 

length: 

170 eclatoms 

SPAR(l) 





north: 

at 

(862,542) , 

length : 

62 eclatoms 

south : 

at 

(862,536) , 

length : 

170 eclatoms 

SPAR (2) 





north : 

at 

(1374,542) 

, length: 

62 eclatoms 

south : 

at 

(1374,536) 

, length: 

170 eclatoms 

SPAR (3) 





north : 

at 

(1886, 542) 

, length: 

213 eclatoms 

south: 

at 

(1886, 536) 

, length: 

17 0 eclatoms 

SPAR (4) 





north: 

at 

(2398,542) 

, length: 

62 eclatoms 

south: 

at 

(2398,536) 

, length: 

170 eclatoms 

SPAR(5) 





north: 

at 

(2910,542) 

, length: 

213 eclatoms 

south: 

at 

(2910,536) 

, length: 

17 0 eclatoms 

SPAR(6) 





north : 

at 

(3422,542) 

, length: 

62 eclatoms 

south: 

at 

(3422, 536) 

, length: 

170 eclatoms 

SPAR (7) 





north: 

at 

(3934, 542) 

, length: 

62 eclatoms 

SOUth: 

at 

(3934, 536) 

, length: 

170 eclatoms 

SPAR(8) 





north: 

at 

(4446, 542) 

, length: 

62 eclatoms 

south: 

at 

(4446, 536) 

, length: 

169 eclatoms 


Spar: cgsparnO Domain: 4 Client atoms: 2 0 026 

Spar: cgsparsO Domain: 1 Client atoms: 24 090 

Spar: cgsparsO Domain: 2 Client atoms: 18 98 0 

Spar: cgsparsO Domain: 3 Client atoms: 17271 
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Spar 

cgsparnl 

Domain: 

14 

Client 

atoms : 

14570 

Spar 

cgsparsl 

Domain: 

11 

Client 

atoms : 

15510 

Spar 

cgsparsl 

Domain : 

12 

Client 

atoms : 

12220 

Spar 

cgsparsl 

Domain : 

13 

Client 

atoms : 

11985 

Spar 

cgsparn2 

Domain: 

24 

Client 

atoms : 

14570 

Spar 

cgspars2 

Domain : 

21 

Client 

atoms : 

15510 

Spar 

cgspars2 

Domain : 

22 

Client 

atoms : 

12220 

Spar 

cgspars2 

Domain: 

23 

Client 

atoms : 

11985 

Spar 

cgsparn3 

Domain: 

36 

Client 

atoms : 

13095 

Spar 

cgsparn3 

Domain: 

35 

Client 

atoms : 

8250 

Spar 

cgsparn3 

Domain : 

34 

Client 

atoms : 

13630 

Spar 

cgspars3 

Domain : 

31 

Client 

atoms : 

15510 

Spar 

cgspars3 

Domain: 

32 

Client 

atoms : 

12220 

Spar 

cgspars3 

Domain: 

33 

Client 

atoms : 

11985 

Spar 

cgsparn4 

Domain: 

44 

Client 

atoms : 

14570 

Spar 

cgspars4 

Domain: 

41 

Client 

atoms : 

15510 

Spar 

cgspars4 

Domain : 

42 

Client 

atoms : 

12220 

Spar 

cgspars4 

Domain : 

43 

Client 

atoms : 

11985 

Spar 

cgsparnS 

Domain: 

56 

Client 

atoms : 

16102 

Spar 

cgsparn5 

Domain : 

55 

Client 

atoms : 

9914 

Spar 

cgsparn5 

Domain : 

54 

Client 

atoms : 

13630 

Spar 

cgspars5 

Domain: 

51 

Client 

atoms: 

15510 

Spar 

cgspars5 

Domain : 

52 

Client 

atoms : 

12220 

Spar 

cgspars5 

Domain : 

53 

Client 

atoms : 

11985 

Spar 

cgsparn6 

Domain : 

64 

Client 

atoms : 

14570 

Spar 

cgspars6 

Domain: 

61 

Client 

atoms : 

15510 

Spar 

cgspars6 

Domain: 

62 

Client 

atoms : 

12220 

Spar 

cgspars6 

Domain: 

63 

Client 

atoms : 

11985 

Spar 

cgsparn7 

Domain: 

74 

Client 

atoms : 

14570 

Spar 

cgspars7 

Domain : 

71 

Client 

atoms : 

66 

Spar 

cgspars7 

Domain: 

72 

Client 

atoms : 

52 

Spar 

cgspars7 

Domain: 

73 

Client 

atoms : 

4497 

Spar 

cgsparn8 

Domain: 

84 

Client 

atoms : 

6758 

Spar 

cgsparsS 

Domain: 

81 

Client 

atoms : 

130 

Spar 

cgspars8 

Domain: 

82 

Client 

atoms : 

104 

Spar 

cgspars8 

Domain: 

83 

Client 

atoms ; 

2429 


/n/auspex6/sl0/chip/euterpe/tools/bin/spargen <clockbias . spargen > clockbias .edif 
/n/auspex6/sl0/chip/euterpe/tools/bin/sofagen -v 

/n/auspex6/sl0/chip/euterpe/compass/vlsi . boo-all <knobstraps . sofagen 

/n/auspex6/sl0/chip/euterpe/proteus/clockbias/run_emerge 

############################# 

#Making clockbias_gards . edif # 

############################# 

Running emerge compiled on Wed Mar 1 18:27:16 GMT 1995 

Consuming edif file clockbias . edif 

Found edif structure: CLOCKBIAS 
Creating status file emerge . stat 
Reading edif library clocklib. edif 

Merging libraries with input edif 
Consuming power table information file 
/n/auspex6/sl0/chip/euterpe/proteus/clockbias/clockbias_gards . tab 
Performing Edif Transformations . . . 
Disgorging edif file clockbias_gards . edif 

Writing edif structure: clockbias_95_gards_4 6_edif Memory usage: 3.855MB 
############################## #Making clockbias_master . edif # 
############################## 

Running emerge compiled on Wed Mar 1 18:27:16 GMT 1995 

Consuming edif file clockbias . edif 

Found edif structure: CLOCKBIAS 
Creating status file emerge. stat 
Reading edif library clocklib . edif 

Merging libraries with input edif 
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Disgorging edif file clockbias_master . edif 

Writing edif structure: clockbias_95_raaster_4 6_edif Memory usage: 3.840MB 
/n/auspex6/sl0/chip/euterpe/proteus/clockbias/clockmask <cbsofa_mask. ly > clockmask. obs rm 
-f *.mobi234 In -s /n/auspex6/sl0/chip/euterpe/technology/mobimos/gards/* .mobi234 . 
/usr/5bin/echo \ 

'readpif . /clockbias .pif \nreadobs . /clockmask. obs\nexit save 1 \ 
> gplace.nic 

/usr/5bin/echo ' PG PHIM__AlP\nPG PHIM_B1P' > clockbias . spn 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 

LM_LICENSE_FILE= /n/auspex6 /si 0/chip/euterpe/ tools/ si/ license/ license .dat 
DISPLAY=thoas : 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex6/slO/chip/euterpe 
/n/auspex6/sl0/chip/euterpe/proteus/clockbias/run_slnet 

** SLNET 1.037 ** SL_NET VI. 000 -- Netlist Manipulator Copyright (c) 1994,1995 SILVAR- 
LISCO. All rights reserved. 

Design: clockbias Started at: 95/03/07 14:09:41 


Loading file "clockbias_gards . edif " . 

Library : clocklib . edif 

Cell [BGVRSLV2] View [NET_VIEW] 

Cell [BGECKBB] View [NET_VIEW] 

Cell [CEDMCTRL_M] View [NET_VIEW] 

Cell [ CEDMCTRL_T J View [NET_VIEW] 

Cell [CEDMCTRL_B] View [NET_VIEW] 

Cell [CEDMCTRL_C] View [NETJVIEW] 

Cell [CGED] View [NET_VIEW] 

Cell [CGEB] View [NET_VIEW] 

Cell [CGEB 2 ] View [NET_VIEW] 

Cell [CGEBMAST] View [NET_VIEW] 

Cell [CGEB2MAST] View [NET_VIEW] 

Library : CLOCKLIB 


Library : clockbias 


Cell 

[cgsparnO] 

View 

[NET 

VIEW] 

Cell 

[cgsparsO] 

View 

[NET~ 

VIEW] 

Cell 

[cgsparnl] 

View 

[NET 

VIEW] 

Cell 

[cgsparsl] 

View 

[NET_ 

VIEW] 

Cell 

[cgsparn2] 

View 

[net" 

"view] 

Cell 

[cgspars2] 

View 

[NET_ 

VIEW] 

Cell 

[cgsparn3] 

View 

[NET_ 

_VIEW] 

Cell 

[cgspars3] 

View 

[NET" 

"view] 

Cell 

[cgsparn4] 

View 

[NET 

VIEW] 

Cell 

[cgspars4] 

View 

[NET 

VIEW] 

Cell 

[cgsparnS] 

View 

[NET" 

"VIEW] 

Cell 

[cgsparsB] 

View 

[NET 

VIEW] 

Cell 

[cgsparn6] 

View 

[net" 

"view] 

Cell 

[cgspars63 

View 

[NET_ 

VIEW] 

Cell 

[cgsparn7] 

View 

[net" 

"view] 

Cell 

[cgspars7] 

View 

[net 

VIEW] 

Cell 

[cgsparn8] 

View 

[NET 

View] 

Cell 

[cgspars8] 

View 

[NET 

_VIEW] 

Cell 

[cgmasteO] 

View 

[net" 

"view] 

Cell 

[cgmastwO] 

View 

[NET 

view] 

Cell 

[cggaf f eO] 

View 

[NET 

view] 

Cell 

[cggaf fwO] 

View 

[NET" 

"view] 

Cell 

[clockbias; 

View 

[NET_VIEW] 


Saving . . . 
[CGED] 
[CGEB] 

[CEDMCTRL_B] 

[CGEB 2] 

[BGECKBB] 

[CEDMCTRL_M] 

[BGVRSLV2] 

[CEDMCTRL_T] 
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[CEDMCTRL_C] 
[CGEBMAST] 
[CGEB2MAST] 
[clockbias] 

Net list Info 


Number of logic types : 11 

Number of nets : 776 

Number of components : 1922 

Number of component pins : 4 744 

Number of pins/comp : 2.468262 

Number of nets/comp : 0.403746 


Size estimation 


| TYPE | # inst | size/inst | total 

size | 


| CGED 

| 1193 

1 1 

| 1193 

| CGEB 

| 277 

| 1 

| 277 

| CEDMCTRL_B 

1 8 

1 1 

1 & 

| CGEB 2 

1 41 

| 1 

1 41 

| BGECKBB 

| 40 

1 1 

| 40 

| CEDMCTRL_M 

| 40 

1 1 

| 40 

| BGVRSLV2 

| 262 

1 1 

| 262 

| CEDMCTRLJT 

1 9 

1 1 

1 9 

| CEDMCTRL_C 

| 1 

| 1 

| 1 

| CGEBMAST 

j 47 

1 1 

| 47 

| CGEB2MAST 

1 4 

| 1 

1 4 


+ 


I TOTAL | 1922 | 1 | 1922 


Warning : No "SL_SIZE" attributes found on the cells! 
Default size (1) was used for all cells. 

To change this default add an attribute "SL_SIZE" to the cells. 

slnet > slnet > slnet > slnet > 14:10:27 Terminating Normally on 95/03/07 

Elapsed CPU time 00:00:30 

Elapsed wall time 00:00:46 
End of Program 


Normal Termination „ . . 

HOME=/n/auspex6/slO/chip/euterpe/tools 

LM_LICENSE_FILE=/n/auspex6/slO/chip/euterpe/ tools/ sl/license/ license . dat 
DISPLAY=thoas : 0 SL_TOTAL_DURATION=5 0 0 CHIPROOT=/n/auspex6/slO/chip/euterpe 
/n/auspex6/sl0/chip/euterpe/tools/sl /bin/invoke pcomp clockbias 
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Requires a minimum license of gardsfel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 
GARDS PCOMP 7.121 -- Physical Compiler 

Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: clockbias Started at: 95/03/07 14:10:31 

PCOMP Version 7.1.21 of August 9, 1994 

Processing Logic description: CLOCKBIAS 
Processing Expansion level: SLNET 

. . . Start of netlist processing. 

. . . Circuit name : CLOCKBIAS 

. . . Processing CDL. 

. . . CHIPNAME : CBSOFA; 


... Processing header of user PDL. 

. . . PHYSICALLIB:PBUILD; 

... Processing header of system PDL. 

. . . PHYSICALLIB : PBUILD; 

... Processing rest of user PDL. 

... Processing rest of system PDL. 

... Processing TDL. 

... TECHNOLOGYLIB: CBSOFA; 

. . . Computed Grid_Size = 10 0 0 

. . . Final Processing. 

. . . Successful physical compilation (with warnings) . 
>>> Loading logical netlist. 

. . . Successful completion. GARDS design file created. 

Terminated at : 95/03/07 14:11:40 

Elapsed CPU time : 0 Hrs 0 Mins 12 Sees 

Elapsed wall clock time : 0 Hrs 1 Mins 9 Sees 
HOME=/n/auspex6/sl0/chip/ euterpe/ tools 

LM_LICENSE_FILE=/n/auspex6/slO/chip/euterpe/tools/sl/license/license . dat 
DISPLAY=thoas; 0 SLJTOTAL_DURATION=5 0 0 CHlPROOT=/n/auspex6/ si 0/ chip/ euterpe 
/n/auspex6/sl0/chip/euterpe/tools/bin/gastatus -d clockbias 
Design: CLOCKBIAS 

Nets: 451 

Pins: 7776 

DRVs reported: 0 

HOME=/n/auspex6/sl0/ chip/ euterpe/ tools 

LM_LlCENSE_FILE=/n/auspex6/ si O/chip/euterpe/ tools/ si /license/ license. dat 
DISPLAY=thoas : 0 SL_TOTAL_DURATTON=5 0 0 CHIPROOT=/n/auspex6/sl0/chip/euterpe 
/n/auspex6/sl0/chip/euterpe/tools/bin/gadf f 2pif clockbias . dff > clockbias .pif Reading (12) 
LOG_TYPE records . . . 

192 3 components read 

1922 placement records generated 
HOME=/n/auspex6/ slO/chip/euterpe/tools 

LM_LlCENSE_FILE=/n/auspex6/slO/chip/euterpe/tools/sl/ license/license .dat 
DISPLAY-thoas : 0 SL_TOTAL_DURATION= 5 0 0 CHIPROOT=/n/auspex6/sl0/ chip/ euterpe 
/n/auspex6/sl0/chip/euterpe/tools/sl/bin/ invoke gplace clockbias -inbat 1 -cmdin 
gplace.nic 

Requires a minimum license of xgplacel_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 
GARDS GPLACE 7.126 -- General Placer 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: clockbias Started at: 95/03/07 14:11:55 
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GPLACE Version 7.1.26 of September 9, 1994 


Loading component hierarchy. . . 

Loading components. . . 

Loading nets. . . 

Loading logical types . . . 

Processing physical types. , . 

Loading cell_types. . . 

Creating net-comp xref table. . . 


Terminated at : 95/03/07 14:15:37 

Elapsed CPU time : 0 Hrs 1 Mins 3 Sees 

Elapsed wall clock time : 0 Hrs 3 Mins 42 Sees 
HOME=/n/auspex6/slO/chip/euterpe/tools 

LM_LICENSE_FILE= /n/auspex6/sl0/chip/euterpe/ tools/ si/ license/license .dat 
DISPLAY=thoas : 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex6/sl0/chip/euterpe 
/n/auspex6/sl0/chip/euterpe/tools/bin/gastatus -p clockbias 
Design: CLOCKBIAS 

Nets: 451 

Pins: 7776 

Placement ; complete 

H0ME= /n/auspex6 / s 1 0 / chip / eut erpe / t ool s 

LM_LICENSE_FlLE=/n/auspex6/slO/chip/euterpe/tools/sl/license/license.dat 

DISPLAY=thoas : 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex6/slO/chip/euterpe 

/n/auspex6/sl0/chip/euterpe/proteus/clockbias/route_clockbias 

Reading LOCAL_NET (13 91) records... 

Reading block list (23) records... 

Listing (451) nets... 

GARDS Pgroute 7.143 -- Power and Ground Router Copyright (c) 1995 SILVAR-LISCO. All 
rights reserved. 

Design: clockbias Started at: 95/03/07 14:15:46 


PGROUTE Version 7.1.4 3 of April 2, 1994 

Reading signal nets. . . 
Reading unconnected nets. . . 
Reading supply nets... 
Reading cells . . . 
Reading chip information. . . 
Reading logical types. . . 
Reading physical types. . . 
Reading components... 

Routing net: PHIM_A1P 

Net is routed. 

Routing net: PHIM_B1P 

Net is routed. 

Routing statistics: 
GARDS wire length: 1134 
Total segments: 54 
Total vias: 56 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 
Design: CLOCKBIAS 

Nets: 451 

Pins: 7776 


95/03/07 14:17:24 

0 Hrs 0 Mins 28 Sees 

0 Hrs 1 Mins 38 Sees 
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Placement : complete 


Requires a minimum license of xgaroutl_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 
** Multilayer Router 7.121 

Copyright (c) 1994 Silicon Valley Research, Inc. All rights reserved. 
Design: clockbias Started at: 95/03/07 14:17:27 

GAROUT Version 7.1.21 of November 28, 1994 


PARAMETERS FOR THIS ENTIRE RUN: 
DELETEOLD = FALSE 
PROTECTPINS = 1 
LBXSHORTEN = 10 
LBYSHORTEN = 10 


CIRCUIT: CLOCKBIAS 
TOLERANCE = 1 UNITS 

ONE MICRON = 1000 UNITS 

HORIZONTAL SEGMENTS PREFERED ON ODD LAYERS VERTICAL SEGMENTS PREFERED ON EVEN LAYERS 
ESTIMATED TOTAL WIRE LENGTH = 1007081 MICRONS 


FILES FOR THIS ENTIRE RUN: 

DESIGN_FILE: clockbias . dff 

LISTING : garout .lis 

CONGVAL : c lockma sk . cvp 

STRATEGY : clockpairs . rcf 

DELAY 0 OBSTRUCTIONS WILL OBSTRUCT ROUTING LAYERS 1 THROUGH 3 WILL TRY ALL INCOMPLETE 
NETS IN THE "NETLIST" FILE 
***** STARTING LINE-SEARCH ROUTING ***** PARAMETERS FOR THIS PASS: 

NETLIST FILE = clockbias_spars . nets 


THRESHOLDS = -1 

ROUTORDER = -1 

NET FLAG = -1 

OUTPUTLEVEL = -1 

TERMOUTPUT = FALSE 
DOGLEG LENGTH ON LAYER 1 SET TO 1000 DFUNITS 

DOGLEG LENGTH ON LAYER 2 SET TO 1000 DFUNITS 

ENFORCE_XOR = FALSE 

BESTESCAPE = 0 

NUMPINTARGS = 5 

X LS LIMIT = 30000 

Y LS LIMIT = 30000 

PIN PAIR LIMIT = -3 

FIRST LAYER = 1 

LAST LAYER = 2 

SEARCH DEPTH = 8 


ROUTING RESULTS: 

***** io% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 8.43% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 20% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 16.86% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 30% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 25.08% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 40% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 38.75% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** so% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 47.18% 
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MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 60 % OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 60.34% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** vo% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 6 9.46% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 80% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 7 7.51% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS - 0 
***** 90% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 85.74% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 100% OF NETS TRIED ***** 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
END OF RUN STATISTICS: 

TOTAL OF 4 690 SEGMENTS AND 363 0 VI AS ON CHIP 
MAXIMUM OF 208 SEGMENTS AND 200 VIAS IN ANY NET 
TOTAL ACTUAL WIRE LENGTH » 62 9836 MICRONS 
NUMBER OF NEW DOGLEG SEGMENTS THIS RUN = 0 
PERCENTAGE OF CONNECTIONS NOW COMPLETE = 88.09% 
TOTAL CONNECTIONS LEFT UNROUTED = 466 
(MAXORD = 80 9, MAXLIN = 809) 

NO NETS TO ROUTE IN LINE- SEARCH PASS (SEARCHDEPTH 20, LAYERS 1 TO 2 ) WILL TRY ALL 
INCOMPLETE NETS IN THE "NETLIST" FILE 
***** STARTING LINE- SEARCH ROUTING ***** PARAMETERS FOR THIS PASS: 
NETLIST FILE ■ clockbias_mast . net s 

THRESHOLDS = -1 

ROUTORDER = -1 

NETFLAG = -1 

OUTPUTLEVEL = -1 

TERMOUTPUT = FALSE 
DOGLEG LENGTH ON LAYER 2 IS 10 0 0 DFUNITS 

DOGLEG LENGTH ON LAYER 3 SET TO 1000 DFUNITS 

ENFORCE_XOR = FALSE 

BESTESCAPE = 0 

NUMPINTARGS = 5 

X LS LIMIT = 30000 

Y LS LIMIT = 30000 

PIN PAIR LIMIT = 0 

FIRST LAYER = 2 

LAST LAYER = 3 

SEARCH DEPTH = 8 

ROUTING RESULTS: 

***** io% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 88.22% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 20% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 88.34% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 30% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 88.57% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 40% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 88.8 0% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 50% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 8 9.14% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 60% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 89.4 7% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 70% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 89.90% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS * 0 
***** 80% OF NETS TRIED ***** 
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PERCENTAGE OF CONNECTIONS NOW COMPLETE = 90.34% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 90% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 90.82% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 100% OF NETS TRIED ***** 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
END OF RUN STATISTICS: 

TOTAL OF 4 816 SEGMENTS AND 3 7 66 VIAS ON CHIP 
MAXIMUM OF 2 08 SEGMENTS AND 200 VIAS IN ANY NET 

TOTAL ACTUAL WIRE LENGTH = 68 9388 MICRONS 
NUMBER OF NEW DOGLEG SEGMENTS THIS RUN = 0 
PERCENTAGE OF CONNECTIONS NOW COMPLETE = 91.31% 
TOTAL CONNECTIONS LEFT UNROUTED = 34 0 
(MAXORD = 809, MAXLIN = 809) 

NO NETS TO ROUTE IN LINE-SEARCH PASS (SEARCHDEPTH 20, LAYERS 2 TO 3 ) WILL TRY ALL 
INCOMPLETE NETS IN THE "NETLIST " FILE 
***** STARTING LINE- SEARCH ROUTING ***** PARAMETERS FOR THIS PASS: 
NETLIST FILE = clockbias_chain . nets 


THRESHOLDS = -1 

ROUTORDER = -1 

NETFLAG = -1 

OUTPUTLEVEL = -1 

TERMOUTPUT = FALSE 
DOGLEG LENGTH ON LAYER 2 IS 10 00 DFUNITS 

DOGLEG LENGTH ON LAYER 3 IS 1000 DFUNITS 

ENFORCE_XOR = FALSE 

BESTESCAPE = 0 

NUMPINTARGS = 5 

X LS LIMIT = 30000 

Y LS LIMIT = 3 0000 

PIN PAIR LIMIT = 0 

FIRST LAYER = 2 

LAST LAYER = 3 

SEARCH DEPTH = 8 


ROUTING RESULTS: 

***** io% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 91.51% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 20% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 91.64% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 30% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 91.74% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 40% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 91.84% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 50% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 91.95% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 60% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 92.07% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 70% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE - 92.18% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 80% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 92.28% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 90% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 92.38% 
MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
***** 10 Q% OF NETS TRIED ***** 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 
END OF RUN STATISTICS: 
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TOTAL OF 48 6 6 SEGMENTS AND 3 85 8 VI AS ON CHIP 

MAXIMUM OF 208 SEGMENTS AND 200 VIAS IN ANY NET 
TOTAL ACTUAL WIRE LENGTH = 728423 MICRONS 
NUMBER OF NEW DOGLEG SEGMENTS THIS RUN = 0 
PERCENTAGE OF CONNECTIONS NOW COMPLETE =92.48% 
TOTAL CONNECTIONS LEFT UNROUTED = 2 94 

(MAXORD = 809, MAXLIN = 809) 

NO NETS TO ROUTE IN LINE- SEARCH PASS (SEARCHDEPTH 20, LAYERS 2 TO 3 ) 
*** NORMAL TERMINATION *** 

Terminated at : 95/03/07 14:22:38 

Elapsed CPU time : 0 Hrs l Mins 4 9 Sees 

Elapsed wall clock time : 0 Hrs 5 Mins 11 Sees 

Requires a minimum license of xgaroutl_3 or gardsl_3 . 
Applicable licenses available at your installation : 
gardsconf ig_3 

Checked out one user token of a gardsconf ig_3 license. 
** Multilayer Router 7.121 

Copyright (c> 1994 Silicon Valley Research, Inc. All rights reserved. 
Design: clockbias Started at: 95/03/07 14:22:42 

GAROUT Version 7.1.21 of November 28, 1994 

PARAMETERS FOR THIS ENTIRE RUN: 
DELETEOLD = FALSE 
PROTECTPINS = 1 
LBXSHORTEN = 10 
LBYSHORTEN = 10 

CIRCUIT: CLOCKBIAS 
TOLERANCE = 1 UNITS 

ONE MICRON = 1000 UNITS 

HORIZONTAL SEGMENTS PREFERED ON ODD LAYERS VERTICAL SEGMENTS PREFERED ON EVEN LAYERS 
ESTIMATED TOTAL WIRE LENGTH = 1007081 MICRONS CHIP CONTAINS SOME PREVIOUS WIRING 
tt OF SEGMENTS = 4866 # OF VIAS = 3858 
ACTUAL WIRE LENGTH SO FAR = 72842 3 MICRONS 

FILES FOR THIS ENTIRE RUN: 

DESIGN_FILE: clockbias . df f 

LISTING : garout . lis 

CONGVAL : dummy . cvp 

STRATEGY : clockbias . rcf 

WILL TRY ALL INCOMPLETE NETS IN THE DESIGN 

***** STARTING LINE- SEARCH ROUTING ***** PARAMETERS FOR THIS PASS : 

NETLIST FILE = dummy. nets 

THRESHOLDS = -1 
ROUTORDER = -1 
NET FLAG = -2 
OUTPUTLEVEL = -1 
TERMOUTPUT = FALSE 
DOGLEG LENGTH ON LAYER 1 
DOGLEG LENGTH ON LAYER 2 
ENFORCE_XOR = FALSE 
BESTESCAPE = 10 
NUMPINTARGS = 5 
X LS LIMIT = 30000 
Y LS LIMIT = 30000 
PIN PAIR LIMIT = 
FIRST LAYER = 1 
LAST LAYER = 2 
SEARCH DEPTH = 8 

ROUTING RESULTS: 
***** io% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 94.27% 


SET TO 10 0 0 DFUNITS 

SET TO 10 0 0 DFUNITS 
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MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 20% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 95.42% 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 30% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE m 96.7 0% 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 40% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 97.85% 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 50% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 98.79% 

MISSING CONNECTIONS IN TRIED NETS THIS PASS - 0 
***** 60% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 99.05% 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 70% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 99.28% 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 80% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 9 9.54% 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 90% OF NETS TRIED ***** 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 99.77% 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
***** 100% OF NETS TRIED ***** 

MISSING CONNECTIONS IN TRIED NETS THIS PASS = 0 
END OF RUN STATISTICS: 

TOTAL OF 5320 SEGMENTS AND 3858 VIAS ON CHIP 
MAXIMUM OF 208 SEGMENTS AND 200 VIAS IN ANY NET 

TOTAL ACTUAL WIRE LENGTH = 104 04 02 MICRONS 

NUMBER OF NEW DOGLEG SEGMENTS THIS RUN = 8 0 

PERCENTAGE OF CONNECTIONS NOW COMPLETE = 100.00% 

TOTAL CONNECTIONS LEFT UNROUTED = 0 
(MAXORD - 363, MAXLIN = 363) 
*** NORMAL TERMINATION *** 


Terminated at : 95/03/07 14:23:28 

Elapsed CPU time : 0 Hrs 0 Mins 3 4 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 46 Sees 
Design: CLOCKBIAS 

Nets: 451 

Pins: 7776 


Placement : complete 

HOME=/n/auspex6/sl0/chip/euterpe/ tools 

LM_LICENSE_FlLE=/n/auspex6/sl0/ chip/ euterpe /tools /si/ license/license . dat 
DISPLAY=thoas : 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex6/slO/chip/euterpe 
/n/auspex6/sl0/chip/euterpe/tools/bin/gastatus -r clockbias 
Design: CLOCKBIAS 

Nets: 451 

Pins: 7776 


Routing 100.00% complete 
HOME=/n/auspex6/sl0/chip/euterpe/ tools 

LM_LlCENSE_FILE=/n/auspex6/slO/chip/euterpe/ tools/ si/ license/license .dat 
DISPLAY=thoas : 0 SL_TOTAL_DURATION=500 CHIPROOT=/n/auspex6/slO/ chip/ euterpe 
/n/auspex6/sl0/chip/euterpe/proteus/clockbias/export_clockbias 
/n/auspex6/sl0/chip/euterpe/compass/vlsi .boo-all 
###Creating clockbias .gil 

GARDS MASKOUT 7.109 -- Mask Data Generator Copyright (c) 1995 SILVAR-LISCO. All rights 
reserved. 

Design: clockbias Started at: 95/03/07 14:23:33 


MASKOUT Version 7.1.09 of April 12, 1994 


Exhibit C12 


Page 116 of 643 


. . .reading physical types. . . 

. . .reading chip information. . . 

. . .reading signal nets. . . 

. . . reading unconnected nets . . . 

. . .reading supply nets. . . 

. . .reading cells. . . 

. . .reading logical types. . . 

. . . reading components . . . 

...converting nets: segments, vias, pads... 

10% 

20% 

30% 

40% 

50% 

60% 

70% 

80% 

90% 

100% 

. . .converting components. . . 


Totals: 

451 signal net (s) . 

2 supply net (s) . 

1224 layer 1 segment (s). 

3944 layer 2 segment (s). 

152 layer 3 segment (s). 

3674 1-2 via{s) . 

184 2-3 via{s) . 

1922 component (s) . 

49994 unused cell(s). 

Total net length on METAL -1 layer is 33862 microns. 
Total net length on METAL- 2 layer is 92 93 33 microns 
Total net length on METAL- 3 layer is 78341 microns. 


Terminated at : 95/03/07 14:23:38 

Elapsed CPU time : 0 Hrs 0 Mins 4 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 5 Sees 

###Target assignment 

Reading (1923) COMP records .. . 

Reading (21) PHYS_TYPE records... 

Reading (451) NET records... 

460 targets appended to file: clockbias . gil ###Creating Compass cell clockbias.ly 
(Compacting. . .done) 

Parsing translation table 
/n/auspex6/sl0/chip/euterpe/tools/lib/gards/xlatemobi . tab 

Design CLOCKBIAS Created 00/00/00 Gil Version 1 
Gil Level 2 

Number of records processed: 61810 
Write layout files 
###Creating Compass cell cgclockbias . ly 
(Compacting. . .done) 

Parsing translation table 
/n/auspex6/sl0/chip/euterpe/tools/lib/gards/xlatemobi . tab 

Design CGCLOCKBIAS Created 00/00/00 Gil Version 1 

Gil Level 2 

Number of records processed: 61811 
Write layout files 
###Protecting targets 
###Simplifying metal layers 
###Compiling target contexts 

Translation of /usr/tmp/piddlesl5 3 95/cgclockbias . cif succeeded. 
Root symbol is called ROOTCELL. 

GARDS GDSGDF 7.108 -- GDS to GDF conversion Copyright (c) 1995 SILVAR-LISCO . All rights 
reserved. 
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Design: piddles Started at: 95/03/07 14:27:16 


Only specified layers will be selected 
database: cgclockbias . gdf will be overwritten layer file read UOM = 10 0 0 METRIC UNITS 
** WARNING ** GDS file : last block length = 1019 

Terminated at : 95/03/07 14:27:16 

Elapsed CPU time : 0 Hrs 0 Mins 0 Sees 

Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 
GARDS GDFPDL 7.12 3 -- Create PDL 

Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: piddles Started at: 95/03/07 14:27:18 


GDFPDL Version 7.1.23 of January 27, 1994 


Initializing ... 
Processing layout data . . . 
Reading name list . . . 
Start processing physical types . . . 
Writing logical to physical mapping . . . 
[CGCLOCKBIAS] 

Potential RED IT error: pin PHI_A2P - pin PHI_A2P_GL0B . 
Targets coincide at x = 1735000, y - 4279000. 
Potential RED IT error: pin PHI_B2P - pin PHI_B2P_GLOB . 
Targets coincide at x = 1736000, y = 4278000. 
Potential REDIT error: pin PHI_A2P - pin PHI_A2P_GLOB . 
Targets coincide at x - 2759000, y = 4279000. 
Potential REDIT error: pin PHI_B2P - pin PHI_B2P_GLOB . 
Targets coincide at x = 2760000, y = 4278000. 
Potential REDIT error: pin PHI_A2P - pin PHI_A2P_GLOB . 
Targets coincide at x = 3783000, y = 4279000. 
Potential REDIT error: pin PHI_B2P - pin PHI_B2P_GL0B . 
Targets coincide at x = 3784000, y = 4278000. 
Potential REDIT error: pin PHI_A2P - pin PHI_A2P_GLOB . 
Targets coincide at x = 4807000, y = 4279000. 
Potential REDIT error: pin PHI_B2P - pin PHI_B2P_GLOB . 
Targets coincide at x = 4808000, y = 4278000. 
Potential REDIT error: pin PHI_A2P - pin PHI_A2P_GLOB . 
Targets coincide at x = 5831000, y = 4279000. 
Potential REDIT error: pin PHI_B2P - pin PHI_B2P_GLOB . 
Targets coincide at x = 5832000, y = 4278000. 
Potential REDIT error: pin PHI_A2P - pin PHI_A2P_GL0B . 
Targets coincide at x = 6855000, y = 4279000. 
Potential REDIT error: pin PHI_B2P - pin PHI_B2P_GLOB . 
Targets coincide at x = 6856000, y = 4278000. 
Potential REDIT error: pin PHI_A2P - pin PHI_A2P_GLOB. 
Targets coincide at x = 7879000, y = 4279000. 
Potential REDIT error: pin PHI_B2P - pin PHI_B2P_GLOB. 
Targets coincide at x = 7880000, y = 4278000. 
Potential REDIT error: pin PHI_A2P - pin PHI_A2P_GLOB . 
Targets coincide at x = 8903000, y - 4279000. 
Potential REDIT error: pin PHI_B2P - pin PHI_B2P_GLOB. 
Targets coincide at x = 8904000, y = 4278000. 
Potential REDIT error: pin PHI_A2P - pin PHI_A2P_GLOB. 
Targets coincide at x = 711000, y = 4279000. 
Potential REDIT error: pin PHI_B2P - pin PHI_B2P_GLOB. 
Targets coincide at x = 712000, y = 4278000. 


One physical type defined. 
%% WARNING: 325 Zero Length Segments. 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 
###Compiling spar/mast obstructions 
Scanning input . . . 


95/03/07 14:27:20 
0 Hrs 0 Mins 2 Sees 
0 Hrs 0 Mins 2 Sees 
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Compacting. . . 

Appending output PDL data . . . 

###Bubbling VDDE/VSSE text from cedmctrl_c into cgclockbias . ly Building cell tree... 


Cells read: 60 
Instances : 1 
Exploding. . . 
Writing .ly file... 
Done 

cp knob* . ly clockbias . ly cgclockbias . ly 
/n/auspex6/sl0/chip/euterpe/compass/baseplate 
cd /n/auspex6/sl0/chip/euterpe/compass/baseplate ; 
/n/auspex6/sl0/chip/euterpe/tools/bin/vlsif ixlib 
cat knobs . emerge . tab > tmp . tab 

awk '{print "createport cgclockbias " $2 " output"}' \ 

knobs . emerge .tab > > tmp . tab 
sed -e ' s / CLOCKBIAS /CG&/ g 1 -e ' s/clockbias/cg&/g ■ \ 

clockbias_master . edif > tmp.edif 
/n/auspex6/sl0/chip/euterpe/ tools/bin/emerge -R -p tmp. tab -n -f -e tmp.edif -o 
cgclockbias .edif 

Running emerge compiled on Wed Mar 1 18:27:16 GMT 1995 

Consuming edif file tmp.edif 

Found edif structure: cgclockbias_95_master_4 6_edif 
Flattening edif; 

flattened 1922 instances; created 3 99 nets in 

cgclockbias_95_master_46_edif 

Consuming power table information file tmp. tab 

Performing Edif Transformations... 
Disgorging edif file cgclockbias . edif 

Writing edif structure: cgclockbias_46_edif Memory usage: 7.918MB rm tmp. tab 
tmp.edif grep ,A B" knobmap.ly | awk 'BEGIN{ width = 100 } {printf ( "\ 
B %d %d %d %d\n\ 
B %d %d %d %d\n\ 
B %d %d %d %d\n\ 
B %d %d %d %d\n" ,\ 
$2,$3,$4,$3+width, \ 
$2, $5-width, $4, $5, \ 
$2, $3 , $2+width, $5, \ 

$4 -width, $3,$4,$5)}' > knobmaptext . ly cp knobmaptext . ly 
/n/auspex6/sl0/chip/euterpe/compass/baseplate 

[finished at Tue Mar 7 14:28:04 PST 1995 -- exit status 0] 
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From: pmayer (Patricia Mayer) 

Sent: Tuesday, March 07, 1995 7:33 PM 

To: 'tbr' 

Cc: 'pmayer 1 

Subject: Re: PCB layout schedule 

I was just wondering if you could respond to this soon? 

Thanks 

-Pattie 

> From pmayer Mon Mar 6 23:28:19 1995 

> Subject: PCB layout schedule 

> 

>Tim, 

> 

> I wanted to revisit our conversation on the PCB layout schedule. 

> 

> On Hestia Main, I added 2 weeks to do the Mnemo module in parallel 

> to Howard laying out the Euterpe module. This really isn't a great 

> significance in my learning if we are to be seperated. Revisit? 

> 

> Need to set priority in the following: 

> 

> Euterpe 

> Mnemo 

> Herminator needed to connect between Pandora and Hestia, Low? 

> Back Plane 

> PCI Bridge - higher than cronus or PCI Hermes 

> Cronus 

> PCI Hermes 

> 

> Please clarify the priorities and I'll plug in the numbers. 

> 

> Thanks 

> -Pattie 

> 
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From: woody (Jay Tomlinson) 

Sent: Tuesday, March 07, 1995 7:36 PM 

To: 'tbr' 

Cc: 'woody' 

Subject: status 

Tim, 

euterpe module: 

I checked in all of my Makefiles and stuff for pandora/p620_00014_0000/ged 
compile. I checked in 2 Makefile, Makefile.ged and Makefile.verilog, eventually 
these should be merge and some of the information put into 
morpheus/Makefile.rules/defs. I *did not* check in the 

morpheus/ged/custom/euterpe/chips_prt file that I hacked because we don't check 
those files in they are automatically generated. I did not release them because 
I have this hacked file to make it work. 

The problem is that the chips_prt generater does not expect a body to have a 
bus at its interface. Rich McCauley says it can be done, but wants to answer 
the body vs gyg as source for the pin map. Rich's view is that the body file 
ought to be the source for pin map type of information. The gyg file can be the 
source for everything else. 

To compile it check out pandora/p620_00014_0000/ged and morpheus. gmake 
morpheus and the copy my euterpe/chips_prt over the one automatically created. 
Then 'gmake' in pandora/p620_00014_0000/ged. 

************************** 
hestia main board: 

The schematic is complete and checked in. I did check in my changes that the 
compiler was going to find. 

I have not attempted to compile this, the only problem I would expect is that 
the calliope chips_prt is not correct. 

I did check in a Makefile in hestia/p620J)0001_0000/ged that is needed to setup 
the startup. concept, etc for browsing the schematic. I assumed you would want 
to do this. 

This schematic needs to be reviewed. I did not verify that all of the gnats PRs 
have been taken care of though I do know that 203 1 and 1777 should be done, 
they just need to be verified. I also know that noel has yet to spec new parts 
for the irout circuit. I put in the old one. 

*************************** 
To Do for main board compile: 

1 . Decide what to do about chips_prt. I vote for sticking with the gyg 
because we already know how to deal with it. 

2. Move all of the schematics to the new directory structure. If you 
attempt to browse the schematic, you will need to set up links to the 
hestia/ged dir (see my set up). 

3. Put together the necessary Makefiles similar to the euterpe module. 
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4. Eventually all of the old stuff should be cvs rm'ed. 
***************** * 

I have to go, but I think that should cover you. 

good luck (see you monday), 

jay 
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From: tbr 

Sent: Tuesday, March 07, 1995 9:55 PM 

To: 'ken (Ken Hsieh)' 

Subject: Re: euterpe (Mike Wageman's machine) is not functioning 

Follow Up Flag: Follow up 
Flag Status: Red 


Ken Hsieh wrote (on Tue Mar 7): 


David told me that euterpe back up on the second reboot. 
However, I found the root disk was making a big noise. I have called 
AVCOM to order a disk to replace it before it crash. We will the disk 
in the next couple of days. 

Ken, did you check with mikeh? We ordered spare drives for the spare 
lis and he should have them in stock by now. 

Tim 
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From: tbr 

Sent: Tuesday, March 07, 1995 10:45 PM 

To: 'pmayer (Patricia Mayer)' 

Cc: 'pmayer' 

Subject: Re: PCB layout schedule 

Follow Up Flag: Follow up 

Flag Status: Red 


Patricia Mayer wrote (on Tue Mar 7): 


I was just wondering if you could respond to this soon? 

Thanks 

-Pattie 

> From pmayer Mon Mar 6 23:28:19 1995 

> Subject: PCB layout schedule 

> 

>Tim, 

> 

> I wanted to revisit our conversation on the PCB layout schedule. 

> 

> On Hestia Main, I added 2 weeks to do the Mnemo module in parallel 

> to Howard laying out the Euterpe module. This really isn't a great 

> significance in my learning if we are to be seperated. Revisit? 

> 

> Need to set priority in the following: 

> 

> Euterpe 

> Mnemo 

> Herminator needed to connect between Pandora and Hestia, Low? 

> Back Plane 

> PCI Bridge - higher than cronus or PCI Hermes 

> Cronus 

> PCI Hermes 

> 

> Please clarify the priorities and I'll plug in the numbers. 


I think you have the right order here. However, the Herminator is not 
to connect between Pandora and Hestia, it's a placeholder for 
otherwise empty slots in the backplane. The PCI Hermes module is the 
link to Hestia. 

Tim 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Tuesday, March 07, 1995 11:15 PM 

'hopper (Mark Hofmann)' 

'mws@microunity.com' 

Re: warning of avoidable veqn bug 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Tue Mar 7): 

Tim B. Robinson writes: 
Mark Hofmann wrote (on Tue Mar 7): 

I haven't poked the code yet, but I think I recall seeing this. 

What would you like Veqn to do with differing bit widths on either side of = ? 

For example: 

0 = foo[2:0] : 3 bits? 
bar[2:0] ==0 : 3 bits? 

bar[2:0] == foo[3:0] : Error ? 

I think we should consider the last one an error. For the special 
case of one side being a constant it ought to get co-erced to the same 
size as the other side. If any non zero bits fall off the LHS, that 
probably ought to be an error too. 

Okay. Mark said much the same. 
I'm working on it. 

I'll make a bit mismatch (where one side is not a constant) an error initially. 
I can change this to a warning and bit extend one field or the other if needed. 

I think if we are specifying fields or busses they oughtta match. 
It's only integers where I think we should infer the width. 
It's safer that way. 


Tim 
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From: 
Sent: 
To: 


tbr 


Tuesday, March 07, 1995 11:20 PM 

'hopper (Mark Hofmann)' 

, mws@microunity.com , 

Re: warning of avoidable veqn bug 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Tue Mar 7): 

Tim B. Robinson writes: 
I think if we are specifying fields or busses they oughtta match. 
It's only integers where I think we should infer the width. 
It's safer that way. 

Okay. 
So... 

if one side is a constant, then pad with O's 

if neither side is constant and the widths mismatch, then error out? 

Yes, and error out if the constant is too big to fit in the field 
width of the other side. 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, March 08, 1995 9:20 AM 

To: 'billz'; 'dickson'; 'doi'; 'jeffm'; 'mws'; 'tbr'; 'woody' 

Cc: 'geert' 

Subject: Test status 


BOM 24 7 running on Zycad 
BOM 244 running on IKOS 


NOTE: gtlbtran_l, doubleextest_0 , 
New business 


regdepend_r25547 238 - miscompare on gmshril6 (should take an 
exception but doesn't) 

tried to recreate with same operands but ran ok - aphrodite /s3 

24295.8960 

244 - This test Ran OK 

stgen_rl3 311_0 24 0 - Miscompare trace on nosferatu 

/s4/res/3395. 13608 

dcache__sz_16k_l 241 - Printed test name then X - rhodan /s3 

2395.6392 

Recreated with icachenoalloc dump (_0) on staypuf t/s3/tbr/euterpe/verilog/bsrc 
icache_func_l 244 - trace on rhodan /s3 5395.2288 (hung) 

doublemctest_0 241 - Traces in /s2 nosferatu 13 95.12332 - verilog 

dump on nosferatu /s5 

hermes_lateturnon 241 - trace on nosferatu /s2 19295.28510 
nb_hermes_l 241 - Failed trace on nosferatu /s2 3395.26649 

atomic_conf lict_l 244 - Hung? rhodan /s3 5395.1189 
Trying to re-create with dcacheannoying2 

sync 1 244 - hung rhodan /s3 4395.9146 

except ion_l 244 - Test fix in 

xlu_f ield_4_l 244 - X very early (looks to be doing a cerberus 

access of octlet 6) 

**** jeff **** RECREATED with dramprint harder 2 see rhodan /s3 83 95.27689 (I had not picked 
up the latest test change) 

mem_u 244 - Printed P then went to X rhodan /s3 

4395 .15296 
inter rupt_U 
gtlb_miss_U 

barrel_U } 244 - All X - rhodan /s3 5395.1338 

bgate_U } 
cache_U } 

icache_stress 244 - X 6395.2961 

dcache_except 244 - dcache tag exception 2 was not recieved when 

expected 

exception bit set in tag but not in GTLB - rhodan /s3 6395.2961 
unix_l 244 - X - trace on rhodan /s3 7395.26886 hung 

cerberrtest 247 - X trace on nosferatu /s2 8395.16920 
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dcache_j?erf_stlt_l 244 just printed failed rhodan /s3 6395.3461 

dcache_perfldst5t_l 244 just printed failed rhodan /s3 6395.3461 

Old Business - Need to reun and if necessary redump these 


cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 

Performance Failures (Test ran to completion but failed performance 
measure) 


dcache_perf_ldlt_l Expected difference between the cached and 

non-cached access = 4600-5050 cycles 

Actually took 3 650 fewer cycles rhodan /s3 24295.8260 
icache_perf_lt_l Expected difference between the cached and 
non-cached access - 46000-50600 cycles 

Actually took 12 3 8 00 fewer cycles rhodan /s3 

26295.14314 

icache_perf_5t_l Expected difference between the cached and 
non-cached access = 58000-63800 cycles 

Actually took 117120 (!) fewer cycles rhodan /s3 

6395.3461 

nb_l Actual accept time = 160:186 Expected accept time 

= 150:180 rhodan /s3 28295.4379 

nb_slow Actual accept time = 160:186 Expected accept time 

= 150:180 rhodan /s3 28295.4379 

Have not yet been run: 


nb_combo_l 

hermes_conf lict_l 
dcache_conf lict_l 

ruptpintest _0 - Need to build a "custom" simulator 

inter leave_l 

inter leave_U 
exception_U 
tlb_U 
synch_U 

Cannot yet be run: 


instr_U 

instr_l 

tlb_l 

insn_l 

nulltest 

XLU tests 


xlu_rotate_l_l 

xlu_rotate_2_l 

xlu_expand_l_l 

xlu_compress__l_l 

xlu_extract_l_l 

xlu_f ield_l_l 

xlu_f ield_2_l 

xlu_f ield_3_l 

xlu_copyswap_l_l 

xlu_copyswap_2_l 

xlu_copyswap_3_l 

x 1 u_c opy s wap_4_l 

xl u_shu f f 1 emux_l_l 

xlu_select_l_l 
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Not yet implemented: 


brcolltest_0 

brcrosstest_0 

brimmlongtest_0 

expriotest_0 

canceltest_0 

hermtotest_0 

cerbtotest_0 

hermerrtest_0 

e ve nt r eg t e s t_ 0 

exintbashtest_0 

cerberror_0 

testerinit_0 

memmap_0 

nbbashtest_0 

cerbarbtests 

hcplltests 

Need Special Simulator Support 


hermesload_0 
hermes load_0 
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Subject: 


Sent: 

To: 

Cc: 


From: 


jeffm (Jeff Marr) 

Wednesday, March 08, 1995 11:28 AM 
'lisar (Lisa Robinson)' 
•jeffm'; 'mws' 
icachenoalloc_v 


Lisa Robinson writes: 
> 

> Went to X so I am running the _0 version. 

> The _V version is on staypuft /s3 /tbr/euterpe/verilog/bsrc . 
> 

> Lisa R. 

I will fix the _V version, though it is not the highest on my list, since there is an _0 
dump. 
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From: craig 

Sent: Wednesday, March 08, 1 995 1 1 :42 AM 

To: 'dbulfer tbr woody' 

Cc: 'pandora' 

Subject: Re: Euterpe module Cerberus clock 


Perhaps the best way would be to bring both these signals out the connector, where the 
connection can be made on the motherboard. 

Craig 
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From: geert (Geert Rosseel) 

Sent: Wednesday, March 08, 1995 3:37 PM 

To: 'sysadmin' 

Subject: ghidra/s3 

Hi, 

I cannot get to ghidra/s3 from ambiorix 

geert@ambiorix /N/auspex/root/sl4/geert 67 % cd /n/ghidra/s3/geert/euterpe/verilog/bsrc 
/n/ghidra/s3/geert/euterpe/verilog/bsrc: Operation would block 

Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


doi (Derek Iverson) 

Wednesday, March 08, 1995 4:26 PM 

'gmo'; 'guarino'; 'jeffm'; 'sandeep'; 'gregg'; 'wayne' 

'hestia' 

Software Bringup Meeting Minutes - March 8, 1995 


Software Bringup Meeting 


March 8, 1995 


Next Meeting: 


March 15 at 10:00 am. 


Attendees: guarino, gmo, sandeep, jeffm, doi, gregg 


New Action Items 


Review of Action Items 


Item: Build test that accesses and runs in a bunch of memory spaces and 

states. 

Who : doi 

Status: In progress. 

03/08 The test currently runs out of ibuffer but accesses data out 
of dbuf, dram, and hermes devices. The support to build 
the tests that specify hermes data regions in in progress (mkimg) . 

Item: Can a single cylinder (in an exception "loop") lock out other 

cylinders? 

Who: jeffm 

Status : Pending . 

03/08 Jeff needs to talk with mws . 

Item: Determine what is initialized (and how) in terp 
Who : gmo 

Status : Pending 

03 08 Gmo took this item. 


Item: Terp needs to model "guaranteed forward progress for cache miss' 

in the same fashion as the hardware does . 
Who: lisa 

Status: In progress. 

03/01 Lisa has contacted mws and is implementing the same scheme 

used by the hardware. 
03/08 Still in progress. 


Item: Tests need to be written to verify performance issues 
Who: lisar 

Status: In progress. 

02/22 We need to flag performance problems as errors. 

Tests could be identified (and perhaps written) to measure 
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and verify performance of the hardware for things like cache 
misses, tlb initialization, exceptions, etc. 

03/01 Lisar has started writing these tests. 

03/08 Work continues. 


Item: Running Real-time Benchmark on Euterpe/Calliope HW Simulator 

(combined with previous "Run real-time test on the HW simulator) 
Who : gr egg , 1 i sar 
Status: In Progress. 

02/08 There are problems getting the benchmark to run on the 
software simulator. Work continues to find out where 
the problems are. The compilers, simulator, kernel, and 
benchmark areas are "frozen' {in terms of checking in 
new changes) until the problem has been identified. 

02/15 It is estimated that by the middle of March we should have 
cycles available on the IKOS and a IKOS compatible calliope 
that can be run with the real-time benchmark. 

Lisar will be the verification resource to help with running 
this application. 

The benchmark is working and now the effort is focused on 
getting it to fit in the real-time and memory budgets. 
03/01 The TV application has bogged down recently but work 
continues . 

It is believed that this won't be ready to run (from the software 
hand the hardware perspective) until April. 
03/08 lisar has starting building a IKOS compatible calliope. 

The benchmark team is looking at a way to build a reduced 
subset of the test. 


Item: Determine what additional terp features are required 

(formally "Status of Euterpe/Mnemo simulation') 
Who : gmo, jef fm 
Status : Pending . 

02/08 Jeffm figured that in 2 - 3 weeks time there would be a need 

for terp/mnemo capability to support the verification effort. 

An issue was raised that this may not be enought time for the 

required additions to terp to be made. 
02/15 Gmo is to create a list of requested features for terp and 

then he and jeffm (and others?) are to review the list and 

determine what will be implemented by terp. 
02/22 Gmo is ready to circulate the list. 
03/01 Nothing new. 

03/08 Gmo has shown a group of people the list but will post it. 


Item: Test interleaved access 
Who: guarino, lisar 
Status: Pending. 

02/08 Loretta started to look at this but requires terp support. 

Terp changes are on hold until the real-time benchmark is 

is running again. 
02/22 Test has been written (interleave) but has not been run on 

hwterp yet. Lisar is going to run this on the hardware simulator. 
03/01 The test has been built, but not run yet. Derek is to check 

to be sure the hermes channels are enabled. 
0 3/08 Ready to run on HW. 


Item: Build microkernel tests for IKOS 
Who: doi, sandeep, iimura 

Status: In progress. Expected completion 2/15 
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02/08 Create images for boot test, snapshot images for microkernel 
tests . 

02/15 doi is still working on modifying the makefiles to build 
the _1 and _2 versions of this. 

iimura is creating a tool that modifies the ELF headers to 
have the proper real addresses (not just virtual) and gmo has 
modified mkimg to be able to understand the new headers. 

02/22 lisar says there are still problems building this . 

iimura is generating a code segment that will run in both 
rom and cerbrom that will proberly initialize dram 
and then branch to the test (which is in dram) . 

03/01 Sandeep is going to add code to boot so it can figure out 
if the cerb node is zero or eight. 

Derek is to start building the kernel tests so they may be 
loaded and run on the hw simulators. 
03/08 Ready to be built for hardware. 


Item: DVT boot 

Who : sandeep 

Status: In progress. 

02/08 First step is to get nano-boot running on the HW simulator. 
02/15 Sandeep has completed the boot code and now we need to 

build a dvt that can be loaded by the DVT boot (i.e. it 

is loaded into the top 8K of D and I buffer) . 

Jeffm commented that for most DVTs, they must be loaded at 

the beginning of D and I buffer and the beginning of ram. 

We will have to come up with an alternative for loading DVTs. 

Sandeep noted that dvts will not be started in event mode 

which is in contrast to jeffm' s mail about the initial state 

for dvts (but we knew this already) . 
02/22 We want to understand if we can modify the DVTs so they do not 

require that they are loaded at the beginning of D&Ibuf and ram. 
03/01 Sandeep is going to implement a DVT boot mechanism. 
03/08 Almost done. Testing and final check- in of changes soon. 


Suspended Items 


Item: Unsnap code 
Who: sandeep , guarino 
Status: Suspended. 

02/15 The issue of restarting the hardware from an IKOS dump 

was discussed and the need for an architectural snap/unsnap 
facility was questioned. 

Since the meeting it has been re -discovered (jeffm wasn't there 
to remind us of an earlier decision) that we are planning on 
loading architectural state into an IKOS simulation and not 
from a total IKOS logic dump. 

We also determined that when it came time to run some 
of the larger tests (real-time benchmark) we would need 
the capability to start an IKOS simulation from an 
architectural dump anyhow. 
03/01 For the short term we are going to focus on a simpler 
approach for loading and running DVTs, the kernel, and 
kernel tests. This item will likely come back in April. 


Item: Refine remote debugging environment 

Who : sandeep 

Status : Suspended 

02/08 We have to decide how control (and state) is to be returned 
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to the debug stub after a test runs. 
02/15 Sandeep is not going to have time to start on this for a while. 


Item: Create performance test plan 
Who: jeffm, guarino 

Status: [11/3 0] No progress as focus is on functionality. 

We continue to run tests to help us compare terp vs hardware 
performance . 

We still need to put together the actual performance tests that 
need to be run on the hardware. 


Completed Items 


Item: Build a longer sync -op test with nb activity. 
Who : guarino 
Status: Done. 


Item: Build and run stress test (without printfs) 
Who : guarino 
Status: Done. 


Item: Specify and Design ISA/ Cerberus Card 

Who: gmo, lisar, dbulfer 

Status: Done (the specify part) 

02/22 gmo, lisar, and dbulfer own the problem of specifying 

the design and assigning resources. 
03/01 The specification meeting happened but design (hw and sw) has 

yet to begin. 

03/08 Requirements posted. This is being removed form the list 
of items the software bringup group will track. 


Test Status and General Discussion 


Jeff talked about current HW and test status. 

I missed most of the discussion printing off the proper version of last meetings minutes. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, March 08, 1995 4:49 PM 

'craig (Craig Hansen)' 

'dbulfer'; 'pandora'; 'woody' 

Re: Euterpe module Cerberus clock 


Craig Hansen wrote (on Wed Mar 8) : 

Perhaps the best way would be to bring both these signals out 

the connector, where the connection can be made on the motherboard. 

Great idea ! with the new pinnout we have plenty of pins to do that . 

Tim 
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From: Curtis Abbott [abbott@microunity.com] 
Sent: Wednesday, March 08, 1995 5:15 PM 
To: 'tbr@microunity.com' 
Subject: Euterpe SDRAM 

Given the 32-bit path, what happens if you connect only 1 SDRAM chip? 
I suppose everything breaks? Is it possible that octlets could come 
back (and go out) with every other 16 bits garbage? 

- Curtis 
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From: 


tbr 


To: 

Cc: 

Subject: 


Sent: 


Wednesday, March 08, 1995 6:28 PM 
'Curtis Abbott' 
'billz'; 'lisar 1 
Euterpe SDRAM 


Follow Up Flag: Follow up 
Flag Status: Red 

Curtis Abbott wrote (on Wed Mar 8): 

Given the 32-bit path, what happens if you connect only 1 SDRAM chip? 
I suppose everything breaks? Is it possible that octlets could come 
back (and go out) with every other 16 bits garbage? 

We got it covered! We have three configurations which support a 16 
bit databus with choice of 1x16, 2x8, or 4x4 parts (16Mbit). Apart 
from halved performance, everything would look the same as normal to 
software. We also have three more configurations to do the same with 
64Mbit generation parts when they become available. 

We have tested it well stand alone, but have not covered any of these 
configurations in system level tests. If you think it may be 
important we need to increase the coverage at that level. 

What is the scenario where we might want this? 


Tim 
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To: 


Sent: 


From: 


Curtis Abbott [abbott@microunity.com] 
Wednesday, March 08, 1995 6:41 PM 
Tim B. Robinson' 


Cc: 'billz@microunity.com'; 'lisar@microunity.com' 
Subject: Euterpe SDRAM 

Tim B. Robinson wrote (on Wed Mar 8): 

Curtis Abbott wrote (on Wed Mar 8): 

Given the 32-bit path, what happens if you connect only 1 SDRAM chip? 
I suppose everything breaks? Is it possible that octlets could come 
back (and go out) with every other 16 bits garbage? 

We got it covered! We have three configurations which support a 16 

Good work! 


We have tested it well stand alone, but have not covered any of these 
configurations in system level tests. If you think it may be 
important we need to increase the coverage at that level. 

What is the scenario where we might want this? 

A cable modem based on Euterpe might need other than onchip memory. 
Clearly, this could be slower than 100MHz, and it would be nice if it 
could be found in increments smaller than 4MB. Given the poor 
availability of 4Mb SDRAM, 2MB increments based on a single 16Mb chip 
would probably be a good solution. 


- Curtis 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, March 08, 1 995 8: 1 9 PM 

To: 'jeffm'; 'rows' 

Cc: 'bilk'; 'dickson'; 'tor'; 'wood/ 

Subject: dramprintharder2 dump 


Is on /s3/tbr/euterpe/verilog/bsrc on staypuf t . 
Lisa R. 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 09, 1 995 2:29 AM 

To: 'Potatoe Chip 1 

Subject: pager log message 


page from chip to geert : 
Thu Mar 9 00:28:23 PST 1995 

/N/auspex6/s4l/euterpe- snapshot /euterpe/verilog/bsrc chip_euterpe crashed 
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From: ken (Ken Hsieh) 

Sent: Thursday, March 09, 1 995 1 1 :23 AM 

To: 'tbr' 

Cc: 'sysadm' 

Subject: Re: tomato mount problem 

> From tbr Wed Mar 8 19:22:36 1995 

> Date: Wed, 8 Mar 1995 19:22:34 -0800 

> From: tbr (Tim B. Robinson) 

> To: sysadmin 

> Subject: tomato mount problem 

> Content-Length: 251 

> 
> 

> tomato can't reach ghidra:/s3 

> 

> tbr@tomato -/euterpe 408 % Is /ghidra/s3 

> /ghidra/s3 not found 

> tbr@tomato -/euterpe 409 % /usr/local/etc/amq -f -u /n/ghidra 

> tbr@tomato -/euterpe 4 1 0 % ! Is 

> Is /ghidra/s3 

Are you sure that you used "/ghidra^"? How about /n/ghidra/s3? 
Ken 

> /ghidra/s3 not found 

> tbr@tomato -/euterpe 4 1 1 % 

> 
> 
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From: 


tbr 


To: 


Sent: 


Subject: 


Thursday, March 09, 1995 1:25 PM 
'ken' 

forwarded message from Charlie Root 


Follow Up Flag: Follow up 
Flag Status: Red 

I see we have another failure. Do you understand this one? 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["51096" "Thu" "9" "March" "95" "03:30:10" "PST" "Charlie Root" "root@auspex0 " nil "1045" "BudTool Backup 
Report 17 Successful, 2 Failed, 1 volume used, 1530480 KB written." " A From:" nil nil "3"]) 
Return-Path: <root@auspex0> 

Received: from auspexO. (auspexO.microunity.com) by gaea.microunity.com (4.1/musel.3) 

id AA07976; Thu, 9 Mar 95 03:30:13 PST 
Received: by auspexO. (4.1/SMI-4.1) 

id AA01618; Thu, 9 Mar 95 03:30: 10 PST 
Message-Id: <9503091 130.AA01618@auspex0> 
From: root@auspexO (Charlie Root) 
To: sysadmin@gaea 

Subject: BudTool Backup Report 17 Successful, 2 Failed, 1 volume used, 1530480 KB written. 
Date: Thu, 9 Mar 95 03:30:10 PST 

03 :30:02> =========== ===== 

03:30:02> Backup Statistics: 

03:30:02> Media server : stacker 1 

03:30:02> Start Time : Wed Mar 8 22:01 :47 1995 

03:30:02> Time completed : Thu Mar 9 03:30:02 1995 

03:30:02> Elapsed time : 05:28:15 

03:30:02> Total data written :1530480 KB 

03:30:02> Overall performance : 77 KB/sec 

03:30:02> Volumes used :1 

03:30:03> Write Retries : 4075 

03:30:03> Number of Requests : 19 

03:30:O3> Successful Requests : 17 

03:30:03> Failed Requests : 2 

03:30:03> Request Retries :7 

03:30:03> Status Summary : 2 requests FAILED! ! 

03 :30:03> ========= ======_==—== — 

03:30:03> Media Summary: 
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From: ken (Ken Hsieh) 

Sent: Thursday, March 09, 1 995 1 :32 PM 

To: tbr' 

Subject: Re: forwarded message from Charlie Root 


I have received two patched from PDC. We will see the result with new patches. 
Ken 

> From tbr Thu Mar 9 11 :25:04 1995 

> Date: Thu, 9 Mar 1995 1 1 :25:03 -0800 

> From: tbr (Tim B. Robinson) 

> To: ken 

> Subject: forwarded message from Charlie Root 

> Content-Length: 1573 

> 

> I see we have another failure. Do you understand this one? 

> 

> start of forwarded message 

> Status: RO 

> X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

> ["51096" "Thu" "9" "March" "95" "03:30:10" "PST" "Charlie Root" "root@auspex0 " nil "1045" "BudTool Backup 
Report 17 Successful, 2 Failed, 1 volume used, 1530480 KB written." " A From:" nil nil "3"]) 

> Return-Path: <root@auspex0> 

> Received: from auspexO. (auspexO.microunity.com) by gaea.microunity.com (4.1 /muse 1.3) 

> id AA07976; Thu, 9 Mar 95 03:30:13 PST 

> Received: by auspexO. (4.1/SMI-4.1) 

> id AA01618; Thu, 9 Mar 95 03:30:10 PST 

> Message-Id: <950309U30.AA01618@auspex0.> 

> From: root@auspex0 (Charlie Root) 

> To: sysadmin@gaea 

> Subject: BudTool Backup Report 17 Successful, 2 Failed, 1 volume used, 1530480 KB written. 

> Date: Thu, 9 Mar 95 03:30:10 PST 

> 

> 03:30:02> =====_======================= =_= 

> 03:30:02> Backup Statistics: 
>03:30:02> Media server : stacker 1 

> 03:30:02> Start Time : Wed Mar 8 22:01 :47 1995 

> 03:30:02> Time completed : Thu Mar 9 03:30:02 1995 
>03:30:02> Elapsed time : 05:28:15 

>03:30:02> Total data written :1530480 KB 

> 03:30:02> Overall performance : 77 KB/sec 
>03:30:02> Volumes used :1 
>03:30:03> Write Retries : 4075 
>03:30:03> Number of Requests : 19 
>03:30:03> Successful Requests : 17 
>03:30:03> Failed Requests :2 
>03:30:03> Request Retries :7 

>03:30:03> Status Summary : 2 requests FAILED!! 

> 03:30:03> ======================================== 

> 03:30:03> Media Summary: 
> 


Exhibit C12 


Page 145 of 643 


From: iisar (Lisa Robinson) 

Sent: Thursday, March 09, 1995 2:13 PM 

To: Vo (Tom Vo)' 

Cc: 'tor'; 'woody' 

Subject: euterpe/verilog/bsrc/ce ceregcore.V 

Tom Vo wrote (on Thu Mar 9): 

Update of /p/cvsroot/euterpe/verilog/bsrc/ce 
In directory ghidra:/s4/vo/euterpe/verilog/bsrc/ce 

Modified Files: 

ceregcore.V 
Log Message: 

fixed inversion with delayed channel disable 
Tom, what would have been the effect of this problem. 
Lisa R. 
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From: vo (Tom Vo) 

Sent: Thursday, March 09, 1995 2:26 PM 
To: 'Lisa Robinson' 

Cc: 'tbr (Tim B. Robinson)'; 'woody (Jay Tomlinson)' 
Subject: Re: euterpe/verilog/bsrc/ce ceregcore.V 

Lisa Robinson wrote .... 

> 
> 

>Tom Vo wrote (on Thu Mar 9): 

> 

> Update of /p/cvsroot/euterpe/verilog/bsrc/ce 

> In directory ghidra:/s4/vo/euterpe/verilog/bsrc/ce 

> 

> Modified Files: 

> ceregcore.V 

> Log Message: 

> fixed inversion with delayed channel disable 

> 

>Tom, what would have been the effect of this problem. 

> 

>Lisa R. 


The channel disable was mistakenly inverted in an earlier 
checkin . We think that in the wrapchsim enviroment , where 
there's no hermes , nb got confused if the channel 
is enabled . The verilog simulator would come back with X-s 
very quicky . 

tvo 
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From: tbr 

Sent: Thursday, March 09, 1995 5:52 PM 

To: 'solo (John Campbell)' 

Cc: 'brianl (Brian Lee)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'Lisa Robinson'; 

Thomas Laidig'; Tom Vo' 

Subject: proteus build from scratch done 

Follow Up Flag: Follow up 

Flag Status: Red 


John Campbell wrote (on Thu Mar 9): 

The proteus build from scratch has completed. We have some changes to 
Makefiles to checkin and release. 

Meanwhile, we should look at the result and see what we think. I need 
some suggestions or just plain looks at files by you folks to see if 
things are rational. 

Lisar and I looked at some of the timing and cap files and saw some 
differences. They may not be relavent or as a result of newer 
models. 

Were you comparing to the snapsht or to /u/chip. I had other evidence 
of something wrong in /u/chip which I fowarded to brinal to investigate. 

We intend to start another build with the new makefiles from scratch 
before the weekend go feedback would be helpful before then. 

torn, any suggestions of where to build a chip on the auspex which 
would end up being the mnemo snapshot. 

Do you mean for the proteus, or the mnemo portion? For now I am using 
the euterpe snapshot for mnemo also. This will have to change as soon 
as we really freeze the euterpe version. 

Tim 
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From: 
Sent: 
To: 
Cc: 


Subject: 


tbr (Tim B. Robinson) 

Thursday, March 09, 1995 5:52 PM 

'solo (John Campbell)' 

'brianl (Brian Lee)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 
'torn (Thomas Laidig)'; 'vo (Tom Vo)' 
proteus build from scratch done 


John Campbell wrote (on Thu Mar 9) : 

The proteus build from scratch has completed. We have some changes to 
Makefiles to checkin and release. 

Meanwhile, we should look at the result and see what we think. I need 
some suggestions or just plain looks at files by you folks to see if 
things are rational. 

Lisar and I looked at some of the timing and cap files and saw some 
differences. They may not be relavent or as a result of newer 
models . 

Were you comparing to the snapsht or to /u/chip. I had other evidence of something wrong 
in /u/chip which I f ©warded to brinal to investigate. 

We intend to start another build with the new makefiles from scratch 
before the weekend so feedback would be helpful before then. 

torn, any suggestions of where to build a chip on the auspex which 
would end up being the mnemo snapshot. 

Do you mean for the proteus, or the mnemo portion? For now I am using the euterpe 
snapshot for mnemo also. This will have to change as soon as we really freeze the euterpe 
version. 


Tim 
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From: solo (John Campbell) 

Sent: Thursday, March 09, 1995 6:03 PM 

To: Tim B. Robinson' 

Cc: 'brianl (Brian Lee)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 

'torn (Thomas Laidig)'; "vo (Tom Vo)' 
Subject: Re: proteus build from scratch done 


as Tim B. Robinson was saying 

. .John Campbell wrote {on Thu Mar 9) : 

The proteus build from scratch has completed. We have some changes 

to 

Makefiles to checkin and release. 

Meanwhile, we should look at the result and see what we think. I 

need 

some suggestions or just plain looks at files by you folks to see if 
things are rational . 

Lisar and I looked at some of the timing and cap files and saw some 
differences . They may not be relavent or as a result of newer 
models . 

..Were you comparing to the snapsht or to /u/chip. I had other evidence ..of something 
wrong in /u/chip which I fowarded to brinal to investigate. 


/u/chip brianl also compared them. see his mail 


We intend to start another build with the new makefiles from scratch 
before the weekend so feedback would be helpful before then. 

torn, any suggestions of where to build a chip on the auspex which 
would end up being the mnerao snapshot . 

..Do you mean for the proteus, or the mnemo portion? For now I am using ..the euterpe 
snapshot for mnemo also. This will have to change as soon ..as we really freeze the 
euterpe version. 

. .Tim 


lisars idea, i think mnemo. any suggestions are all right with me. we need to rebuild 
from scratch to test the changes we will make. we should do that tonight at 5 unless you 
say not to. 


regards, 

solo a.k.a. John Campbell x516 
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From: lisar (Lisa Robinson) 

Sent: Friday, March 10, 1995 9:44 AM 

To: 'jeffm'; *tbr'; 'bitlz'; 'mws'; 'dickson'; 'woody' 

Cc: 'doi'; 'geerf 

Subject: test status 


BOM 24 7 running on Zycad 
BOM 244 running on IKOS 
Building 24 9 on IKOS 


New business 

regdepend_r2554 7 238 
exception but doesn't) 

24295.8960 


stgen_rl3 311_0 
/s4/res/3395. 13608 


raiscompare on gmshrilS (should take an 

tried to recreate with same operands but ran ok - aphrodite /s3 
This test Ran OK on IKOS am running again on Zycad 
24 0 - Miscompare trace on nosferatu 


Recreated with icachenoalloc dump (_0) on staypuf t/s3 /tbr/euterpe/verilog/bsrc 
icache func 1 


doub 1 era c t e s t_0 

hermes_lateturnon 241 

nb_hermes_l 

atomic conflict 1 244 


244 - trace on rhodan /s3 53 95.2288 (hung) 
Fix in 249 

241 - HW fix in 249 
trace on nosferatu /s2 19295.28510 
241 - Test fix in running now 
Hung? rhodan /s3 5395.1189 


Trying to re-create with dcacheannoying2 

sync_l 244 - hung rhodan /s3 4395.9146 


xlu field 4 1 


244 


using dram before doing init seq 


**** Jeff **** RECREATED with dramprintharder2 see rhodan /s3 8395.27689 (I had not picked 
up the latest test change) 
dcache_s z_l 6k_l 
2395.6392 

244 


mem_U 
4395. 15296 
interruptU 
gtlb_miss_U 
barrel_U 
bgate_U 

cache_U 
5395.1338 

icache_stress 

dcache_except 
expected 


unix_l 
cerberrtest 


241 - Printed test name then X - rhodan /s3 
Printed P then went to X rhodan /s3 


244 - All X - rhodan /s3 5395.1338 
} 

244 - X traces on rhodan /s3 likedriverlog 


244 - X /s3 rhodan 10395.8826 (and 6395.2961) 

244 - dcache tag exception 2 was not recieved when 

exception bit set in tag but not in GTLB - rhodan /s3 63 95.2961 
trying to re-create with dcacheharder5 

244 - Fix in need to re- run 

247 - X trace on nosferatu /s2 8395.16920 
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dcache_perf_stlt_l 244 - Test fix in need to re- run 

dcache_perf_ldst5t_l 244 - Test fix in need to re-run 

Old Business - Need to reun and if necessary redump these 


cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 

Performance Failures (Test ran to completion but failed performance 
measure) 


dcache_perf_ldlt_l Expected difference between the cached and 

non-cached access = 4600-5050 cycles 

Actually took 3650 fewer cycles rhodan /s3 24295.8260 
icache_jperf_lt_l Expected difference between the cached and 
non- cached access = 46000-50600 cycles 

Actually took 12 3 8 00 fewer cycles rhodan /s3 

26295.14314 

icache_perf_5t_l Expected difference between the cached and 
non-cached access = 58000-63800 cycles 

Actually took 117120 (!) fewer cycles rhodan /s3 

6395.3461 

nb_l Actual accept time - 160:186 Expected accept time 

= 150:180 rhodan /s3 28295.4379 

nb_slow Actual accept time = 160:186 Expected accept time 

= 150:180 rhodan /s3 28295.4379 

Have not yet been run: 


nb_c ombo_l 

addr_map_rom - new but doen't compile 

herme s_c on f 1 i c t _1 
dcache_conf lict_l 

ruptpintest_0 - Need to build a "custom" simulator 

inter leave_l 

interleave_U 
exception_U 
tlb_U 
synch__U 

Cannot yet be run: 


instr_U 

instr_l 

tlb_l 

insn_l 

nulltest 

XLU tests 


xlu_rotate_l_l 

xlu_rotate_2_l 

x lu_expand _1„1 

xlu_compress_l_l 

xlu_extract_l_l 

xlu_field_l_l 

xlu_f ield_21 

xlu_field_3_l 

xlu_copyswap_l_l 

xlu_copyswap_2_l 

xlu_copyswap_3_l 

x 1 u_copy s wap_4_l 

xlu_shuf f lemux_l_l 

xlu select 1 1 
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Not yet implemented: 


brcolltest_0 

brcrosstest_0 

brimmlongtest_0 

expriotest_0 

canceltest_0 

hermtotest_0 

cerbtotest_0 

hermerrtest_0 

eventregtest_0 

exintbashtest_0 

cerberror_0 

testerinit_0 

memmap_0 

nbbashtest_0 

cerbarbtests 

hcplltests 

addr_mad_void 
addr_map_mc 
addr_map_c e rb 
addr_map_herme s 

node -boot 


Need Special Simulator Support 


hermesload_0 
hermes load_0 
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From: tbr 

Sent: Friday, March 10, 1995 1 0:49 AM 

To: 'bobm' 
Subject: PLLO divide ratio 

Follow Up Flag: Follow up 
Flag Status: Red 

A small point, but there should be a reference to note 'a 1 in the 
description of the PLL1 divide ratio in the euterpe micro-architecture. 

Tim 
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From: bobm (Bob Morgan) 

Sent: Friday, March 10, 1995 11:24 AM 

To: 'tbr 1 

Subject: Re: PLLO divide ratio 

I'm sorry, I'm not sure what you mean. Are you talking about 
the description in cerberus octlet 3 1 ? What is note 'a'? 
Thanks, 
Bob 

> From tbr Fri Mar 10 08:48:59 1995 

> Date: Fri, 10 Mar 1995 08:48:56 -0800 

> From: tbr (Tim B. Robinson) 

> To: bobm 

> Subject: PLLO divide ratio 

> Content-Length: 144 

> 
> 

> A small point, but there should be a reference to note 'a* in the 

> description of the PLL1 divide ratio in the euterpe micro-architecture. 

> 

>Tim 

> 
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From: geert (Geert Rosseel) 

Sent: Friday, March 10, 1995 2:52 PM 

To: 'stick' 

Cc: 'tor' 

Subject: euterpe caches 

! 


Hi, 

We are trying to free up some space on Euterpe and Mouss 
suggested to look into making the caches and tags smaller 
now that they onl have to run at 1 .08 GHz and not 1 .3 GHz. 

Is there any possibility of reduing the sizes of the 
word-line drivers on the caches and tags and save 
us some area ? How much work would be involved ? 

Thank's 
Geert 
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From: tbr 

Sent: Friday, March 10, 1995 4:04 PM 

To: 'geert (Geert Rossee!)* 

Cc: 'stick' 

Subject: euterpe caches 

Follow Up Flag: Follow up 

Flag Status: Red 


Geert Rosseel wrote (on Fri Mar 10): 


Hi, 

We are trying to free up some space on Euterpe and Mouss 
suggested to look into making the caches and tags smaller 
now that they onl have to run at 1 .08 GHz and not 1 .3 GHz. 

Is there any possibility of reduing the sizes of the 
word-line drivers on the caches and tags and save 
us some area ? How much work would be involved ? 

We should bear in mind thought that we never really made it at 1 .3 GHz 
allowing for setup and hold times in the SOFA. We should also take 
account of knob setting 6. 

Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Friday, March 10, 1995 4:04 PM 
'geert (Geert Rosseel)' 
'stick' 

euterpe caches 


Geert Rosseel wrote (on Fri Mar 10) : 


Hi, 


We are trying to free up some space on Euterpe and Mouss 
suggested to look into making the caches and tags smaller 
now that they onl have to run at 1.08 GHz and not 1.3 GHz. 

Is there any possibility of reduing the sizes of the 
word- line drivers on the caches and tags and save 
us some area ? How much work would be involved ? 

We should bear in mind thought that we never really made it at 1 . 3GHz allowing for setup 
and hold times in the SOFA. We should also take account of knob setting 6. 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Friday, March 10, 1995 7:44 PM 

To: 'mws' 

Subject: icachenoalloc 


New _0 dump on staypuft. 
Lisa R . 

/s3/tbr/euterpe/verilog/bsrc 
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From: mws (Mark Semmelmeyer) 
Sent: Saturday, March 11, 1995 3:12 AM 
To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn' 
Subject: euterpe/verilog/bsrc/cj micbr.tst pcbhnd.tst 

Update of /p/cvsroot/euterpe/verilog/bsrc/cj 

In directory clytemnestra:/N/auspex2/s24/mws/euterpe/verilog/bsrc/cj 

Modified Files: 

micbr.tst pcbhnd.tst 
Log Message: 

cj/*.tst: Reduce size of instruction queue from 7 to 4 quadlets by 
eliminating all of hexlet 1 (leaving only hexlet 0). 
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From: mws (Mark Semmelmeyer) 
Sent: Saturday, March 11 , 1 995 3: 1 4 AM 
To: 'euterpe-checkins-disf; 'lisar'; 'tbr'; 'torn' 
Subject: euterpe/verilog/bsrc/tst drvchk.V 

Update of /p/cvsroot/euterpe/verilog/bsrc/tst 

In directory clytemnestra:/N/auspex2/s24/mws/euterpe/verilog/bsrc/tst 

Modified Files : 
drvchk.V 
Log Message: 

Compatible with recent strDat detour thru SR and auindx— >au. 
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From: mws (Mark Semmelmeyer) 

Sent: Saturday, March 1 1 , 1 995 3:20 AM 

To: 'euterpe-checkins-dist'; 'lisar 1 ; 'tor'; 'torn' 

Subject: euterpe/verj!og/bsrc/uu evblm.prio uu.V uuprblmrfXVeqn uuprblmrlO.Veqn uuprblmrH.Veqn 
uuprblmr12.Veqn uuprblmr13.Veqn uuprblmr5.Veqn uuprblmr7.Veqn uuprblmr8.Veqn 
uuprblmr9.Veqn uuprblmwm.Veqn 

Update of /p/cvsroot/euterpe/verilog/bsrc/uu 

In directory cyclops:/N/auspex6/s24/mws/euterpe/verilog/bsrc/uu 

Modified Files: 

evblm.prio uu.V uuprblmrO.Veqn uuprblmrlO.Veqn uuprblmrll.Veqn 
uuprblmrl2.Veqn uuprblmrl3.Veqn uuprblmrS.Veqn uuprblmr7.Veqn 
uuprblmr8.Veqn uuprblmr9.Veqn uuprblmwm.Veqn 
Log Message: 

uu/evblm.prio uu/uu.V uu/uuprblm{rO J r5,r7,r8,r9,rlO,rl ljrU.rlS.wmJ.Veqn: 

Some tests like dramprintharder2_0, bgate_U, interrupt u, gtlb_miss_u, and 

barrel^u created a 1 0 or 1 5 tick nonblocking load use dependency on a 

reg that had not been previously written non-X. The speculative load use 

job, if a memory op itself, was then using its generated X address to get 

an X LTLB miss. Separated isRsrvd from early part of problem pipe so that 

load use hiccup could blindly kill the uncertain prblms. Fix is much broader 

than the mem case to handle the 5 tick separation FXDPNT case (inspection). 
uu/uuprblmr5. Veqn: Forgot that new NBLDUSE must be higher priority than 

new LTLBMISS because the former indicates the latter may be X. 
uu/uuprblmr8.Veqn: Inspection found ltlb miss was higher prio than BR!=Lva. 
uu/uuprblmrl 1 .Veqn: Inspection found incoming REPELFAIL treated as illegal. 
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From: mws (Mark Semmelmeyer) 
Sent: Saturday, March 11, 1995 3:31 AM 
To: 'euterpe-checkins-dist'; 'lisar'; *tbr'; 'torn' 
Subject: euterpe/verilog/bsrc euterpe. status 

Update of /p/cvsroot/euterpe/verilog/bsrc 

In directory cyclops:/N/auspex6/s24/mws/euterpe/verilog/bsrc 

Modified Files: 

euterpe. status 
Log Message: 

Silly Logic: AT sends ATcachAbleRl 1 fixed as part of icachenoallocate fix. 
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From: mws (Mark Semmelmeyer) 

Sent: Saturday, March 1 1 , 1 995 3:38 AM 

To: 'doi'; 'lisar 1 ; 'tbr'; 'torn'; 'chip' 

Cc: 'euterpe-checkins-dist' 

Subject: Release of BOMs by mws (euterpe) 

Checkin Message: 

uu/evblm.prio uu/uu.V uu/uuprblm{r0,r5,r7,r8,r9,rl0,rl l,rl2,rl3,wm}.Veqn: 
Some tests like dramprintharder2_0, bgate U, interrupt_u, gtlb_miss_u, and 
barrel_u created a 10 or 1 5 tick nonblocking load use dependency on a 
reg that had not been previously written non-X. The speculative load use 
job, if a memory op itself, was then using its generated X address to get 
an X LTLB miss. Separated isRsrvd from early part of problem pipe so that 
load use hiccup could blindly kill the uncertain prblms. Fix is much broader 
than the mem case to handle the 5 tick separation FXDPNT case (inspection). 

uu/uuprblmr5.Veqn: Forgot that new NBLDUSE must be higher priority than 
new LTLBMISS because the former indicates the latter may be X. 

uu/uuprblmr8.Veqn: Inspection found ltlb miss was higher prio than BR!=Lva. 

uu/uuprblmrl l.Veqn: Inspection found incoming REPELFAIL treated as illegal. 

gt/pimlib.pl gt/gt.V: tbr's new placement & removed commented out logic. 

tst/drvchk.V: Compatible with recent strDat detour thru SR and auindx->au. 

cj/*.tst: Reduce size of instruction queue from 7 to 4 quadlets by 
eliminating all of hexlet 1 (leaving only hexlet 0). 

BOM Update in euterpe BOM 3.462 
BOM Update in euterpe/verilog BOM 3.366 
BOM Release in euterpe/verilog/bsrc BOM 250.0 
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From: chip (Potatoe Chip) 

Sent: Saturday, March 1 1 , 1 995 3:44 AM 

To: 'mws' 

Subject: output of euterpe/verilog/bsrc/.checkoutrc 


Sat Mar 11 01:38:08 PST 1995 (mws Sat, 11 Mar 1995 01:37:48 -0800) 
euterpe/verilog/bsrc 

[Release BOM (V250.0) in euterpe/verilog/bsrc (Sat Mar 11 01:38:08 PST 
1995) ] 


Dir euterpe/verilog/bsrc BOM 250.0 

32.7 . checkoutrc 

73.1 lcesnk.ut 

116.1 ldr_basic.ut 
1.215 Makefile 

1 . 52 Makefile . share 

40.46 Makefile. tst 

27.16 Makefile. vo 

2 7.11 TODO 

68.5 a_eu t e rp e_wr ap . parm 

35.4 analog eut erpe . hwc 
18 3.5 c_euterpe_wrap . parm 

231.2 c_euterpe_wrap . parm . al t 

35.5 clockbias . hwc 

168.1 corridor. obs 

68.3 d_euterpe_wrap . parm 

80.5 dcells.pif 
7.1 doexcldlist 
80.1 dummy. rcf 
6.379 euterpe.V 

12.6 euterpe . conf ig 
24.35 euterpe . status 
(24.34) 

6.76 euterpe_driver . V 

6 . 25 euterpe_pads . V 

15 . 84 euterpe_wrap. V 

15.4 euterpe_wrap . parm 
134 . 4 export_obs 

119.4 export_subblock 
20.1 fake.pl 

41.11 genpim2.pl 

47 . 10 gettst 

65.5 h_euterpe_wrap . parm 

12 . 1 hwcnets 

187 . 5 i_euterpe_wrap . tb 
187 . 9 i_euterpe_wrap . vhdl 

91 . 4 levellog 

134.2 levelmlog 
168.1 linesearch. ercf 
168.1 maze. ercf 

1.18 opchart 

37.6 pimlib.pl 

131.3 preptest 
70.3 purgetst 
131.1 runs 
134.7 runvtest 

240.1 s_euterpe_wrap . parm 

62.10 stashtst 

4 0.4 subblk . rcf 

52.5 tbr3_v2e . conf ig 

3 5.1 toplev .power . tab. local 
41.5 toplev. rcf 

12.2 tst_v2e . conf ig 
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Dir euterpe/verilog/bsrc/at BOM 58.0 

4.1 . checkoutrc 

1 . 13 Makefile 

1.42 at.V 

1.7 at.h 
51.3 at. pirn 

2 8.6 at .power . tab. top 
3 . 19 at_control .pirn 

1.3 atcdwe2.pla 
1.1 atcteql.pla 

1 . 1 atcylenc . pla 

1.4 atdisallowxc .pla 

25 . 2 atgtlbcnf let . Veqn 

1.5 atgtmissxc. Veqn 

44.3 atillglpa. Veqn 
2 . 3 atnbreq. Veqn 
1.22 atpaded. Veqn 

1 . 2 atpaselgen2 . Veqn 
1 . 1 atpaselgen64 . V 

1 . 1 atpaselgenS . Veqn 

1.17 atpr chk . Veqn 

1 . 2 atvabyp . Veqn 
1.2 atxcenbl.pla 

1.1 atxcfrz.Veqn 

4.6 clean- request 

1.2 genatcteql58.pl 
l.l genatpasel.pl 

3.8 genpim.pl 

3.1 genptab.pl 

3 . 9 pimlib.pl 

Dir euterpe/verilog/bsrc/au BOM 29.0 

14.1 . checkoutrc 

1.9 Makefile 

16.7 au. power . tab. top 

1.19 auindx.V 
12.6 auindx . pirn 
14.5 clean-request 

12.4 genpim.pl 

12.1 pimlib.pl 

14.3 power . tab. local 

Dir euterpe/verilog/bsrc/cc BOM 70.0 

9.2 .checkoutrc 

1 . 20 Makefile 
1.73 cc.V 

63.3 cc. flat. pirn 

3 2.4 cc .power . tab . top 

1.18 cc.ut 

4 9.4 cc_custom.pim 
2 8.5 cccount .pla 

28.4 cchexcount . pla 

60.2 cchold.Veqn 

4 0.5 eclatedirty . Veqn 

51.5 ccrcv .Veqn 
28.17 ccseq.Veqn 
24.15 ccstart.Veqn 
1.20 cctester.V 

1 . 1 cctester .h 

14.10 clean-request 

5.12 genpim.pl 

5.12 pimlib.pl 

5.1 power. tab. local 
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Dir euterpe/verilog/bsrc/cdio BOM 42 . 0 

19.8 . checkoutrc 

1.12 Makefile 

1.18 cdio.V 

34.7 cdio. power , tab. top 

7.1 cdio.ut 

28.4 cdio_control .pirn 

25.5 clean- request 

7.6 genpira.pl 
3.10 genptab.pl 
7.12 pimlib.pl 

Dir euterpe/verilog/bsrc/ce BOM 70.0 

1.16 Makefile 

1.10 Makefile .gar ds 

59.1 Makefile . irsim 

1.1 ce.config 
2.14 ce_cras2ecl.V 

2.12 ce_flash.v 

17.6 ce_kybd.V 
17.4 ce_kybdcntr . V 

32.7 ce_mck.V 
2 . 8 ce_seg7 .V 

1.5 ceclockbiasbuf . V 

1.17 cecore.V 

1 . 2 cedmctrl . V 
1.4 cedractrlm.V 

1.2 cedractrlt.V 
1.8 cedpreg.V 

1 . 1 celoosends . v 

1 . 11 cemaster . V 
1 . 6 cerb . in 

1.7 cerbctrlreg. V 
1.4 6 cerberus. V 
1.22 cerberus . cpif 

1.4 cerberus. rcf 

1 . 5 cerbnobreg . V 

1.4 cerbskewreg. V 

1 . 8 cerbtempreg . V 
1.36 cerbtest.V 

1.6 ceregbuf.V 
1.30 ceregcore . V 

1 . 17 ceslave . V 

1 . 5 cetstmux. V 

Dir euterpe/verilog/bsrc/cg BOM 9.0 

1.8 Makefile 

Dir euterpe/verilog/bsrc/cj BOM 102 . 0 

4 6.4 .checkoutrc 

18.2 libr.ut 
18.2 liss.ut 
1.36 Makefile 

2.13 br.tst 

1.18 cj.V 

1.3 cj.h 
62.6 cj .pirn 

69.10 cj .power . tab. top 

13.31 cjrst.tst 

4 8.7 clean- request 

1.9 freel.tst 
4 2.2 genpim.pl 
4 7.5 genptab.pl 
11.19 hic.tst 
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1.14 

hold. tst 

3 .18 

ifbr . tst 

23 .6 

ifpred3-ll.tst 

20 .4 

ifpred3-2 .tst 

5 .25 

micbr . tst 

(5.24) 


5 .13 

pcbhnd. tst 

(5 . 12 ) 


42 .3 

pimlib.pl 

78.6 

rsrvd . tst 

93 .3 

rupt . tst 

Dir 

euterpe/verilog/bsrc/ck 

10.3 

. checkout rc 

1.8 

Makefile 

9.2 

ck. V 

17.6 

ck . power . tab . top 

1.3 

cktop. V 

11 . 1 

clean 

12 .2 

clean- request 

10 . 2 

cjenpim . pi 

10.5 

pimlib.pl 

Dir 

euterpe/verilog/bsrc/cp 

9.3 

. checkoutrc 

1.8 

Makefile 

9.6 

clean- request 

1.28 

cp.V 

7 .13 

cp.pim 

19.7 

cp . power . tab . top 

41.1 

cph.pira 

41.1 

cpl . pin 

5.7 

genpim .pi 

5 . 3 

piml ib.pl 

5.10 

power . tab . local 

Dir 

euterpe/verilog/bsrc/ctiod 

1.2 

. checkoutrc 

1.6 

Makefile 

7.1 

bram. init 

1.5 

clean- request 

7.1 

ctd. in 

1.7 

ctiod.V 

12 .6 

ctiod. power . tab . top 

6.3 

ctiod. ut 

1.3 

ctiodtester .V 

6.1 

ctiodtester .h 

1 . 3 

ctwe . Veqn 

1.1 

genpim . pi 

1 . 5 

genptab .pi 

1.9 

pimlib.pl 

Dir 

euterpe/verilog/bsrc/ctioi 

3 . 1 

. checkoutrc 

1.5 

Makefile 

4.4 

clean- request 

1. 11 

ctioi .V 

1.4 

ctioi .pirn 

9 . 7 

ctioi . p owe r . t ab . t op 

1.2 

genpim . pi 

1 . 1 

pimlib.pl 

4.5 

power . tab . local 

Dir 

euterpe/verilog/bsrc/dp 


BOM 23 .0 


i 
| 

BOM 44.0 


BOM 22.0 


BOM 21.0 


BOM 41.0 
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1.32 

Makef ile 

1.38 

dp.V 

1 .29 

dp top . v 

29.4 

dpwrap . V 

13 .11 

mstepc . V 

Dir 

euterpe/verilog/bsrc/dr 

32 .3 

. checkoutrc 

1.29 

Makefile 

1.4 

README 

62 .1 

c2e .pirn 

33 .6 

clean- request 

12 .1 

clocksub 

1.24 

dr.V 

1.1 

dr. clocks. ut 

1.13 

dr . conf ig.h 

43 .4 

dr . power . tab . top 

1.9 

dr .ut 

1.2 

dram . registers 

1.1 

drba .pla 

7 . 10 

drbank . V 

1 . 7 

drbankarb . pla 

62 .1 

drbankcontrol . pirn 

1.3 

drbankc sm . pi a 

3 .6 

drbanksel . Veqn 

1.3 

drcd.pla 

1.2 

drclockphase .pla 

1.3 

dr col scram. pla 

4 . 4 

drconf ig2bs . pla 

1.3 

drcsm. states .h 

1.2 

drcsmdecode .pla 

10.3 

drinstantiate . h 

1.3 

droktoact . pla 

1.2 

droktopre.pla 

1.1 

drokt oread . pla 

1.3 

droktowrite .pla 

3 .14 

drout . V 

5.3 

droutde2Sel .pla 

1.4 

drpads . V 

1.2 

drpagecontrolstack . pla 

1.2 

drpagecsm.pla 

1.1 

drpagev.pla 

1.3 

drpmgen . pla 

1.1 

drpop ,pla 

3.5 

drprbcsm.pla 

1.3 

drrc .pla 

1.4 

drreadcount . V 

62 .1 

drreadcount . pirn 

1.3 

drreadcountsel . pla 

1.3 

drresetseq.pla 

1.3 

drrowscram . pla 

1.1 

drrp .pla 

1.5 

drsamplephase . pla 

1.3 

dr seqcheck . pla 

3.1 

drspacematch . Veqn 

6.2 

drtagqc .pla 

1. 15 

drtester . V 

1.5 

drtester.h 

1.8 

drtop . V 

27. 1 

drtop2 .V 

1 . 3 

drwritecount .pla 

1.3 

drwritedsel . pla 

20 . 11 

genpim .pi 

39.2 

genptab.pl 

20 .11 

pimlib .pi 
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Dir euterpe/verilog/bsrc/dr/conf ig BOM 2 . 0 

1.1 Makefile 

1 . 1 dram . datasheet . explained 

1.1 dram. datasheet .nec . 10 

1.1 dram. datasheet. nec. 12 

1.1 dram. system. datasheet 

1.1 marg.c 

1 . 1 system . datasheet . explained 

Dir euterpe/verilog/bsrc/dr/dram BOM 6.0 

1.4 Makefile 

1 . 1 README 

1.1 byl6_64m.ut 

1.1 by8_16m.ut 

1.1 by8_64m.ut 

1.1 sdram.V 

1.2 sdram.h 

1.1 sdram. small . h 

1 . 1 sdram . ut 

1 . 1 spy . h 

1.3 tester. V 
1.1 tester. h 

Dir euterpe/verilog/bsrc/dr/dram/mit BOM 4 . 0 

1 . 3 Makefile 

1 . 1 mitsubishi . sdram. model 

1.1 op . v 

1 . 1 sdram . v 

Dir euterpe/verilog/bsrc/drio BOM 15.0 

3.4 . checkoutrc 
1.4 Makefile 

5.2 clean- request 
1.2 drio.V 

9.6 drio. power. tab. top 

1 . 1 genpim . pi 

1.1 pimlib.pl 

1.1 power . tab. local 

Dir euterpe/verilog/bsrc/es BOM 81.0 

4 5.1 .checkoutrc 

1.23 Makefile 

45.10 clean-request 

5.42 es.V 

5.44 es.pim 

65.9 es .power. tab. top 

40.10 es_xlu,V 
1.16 esaddbyt.V 
60.4 esaddbyta.v 
60.3 esalmsum.V 
60.3 esalmsumb.V 
1.27 esalu64.V 
1.10 escla.V 
1.87 escntrl.V 
1.29 esomux . V 

I. 4 estop. V 
37 . 12 genpim.pl 
3 7.1 pimlib.pl 

13.6 power . tab . local 

Dir euterpe/verilog/bsrc/gf BOM 2 8.0 

II. 3 . checkoutrc 
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I. 15 

II. 5 
9.7 
1.6 
4.8 
19.7 
1.3 
1. 11 
1.1 
9.1 

Dir 

39.3 
8.3 
9.4 
1.26 
41.5 
26.6 
14 .3 
24 .4 
7 .15 

2 . 24 
{2.23) 
54 .7 
26.21 
7.25 
9.4 

10 .12 
7.4 
7 .34 
7.5 
7.7 

7 .22 
7.4 
26.9 
(26.8) 

Dir 

35.8 
1.28 
40.6 
34 .5 
32.9 
12 .5 
1.47 

3 .14 
8.5 
68 . 5 
73 .11 
68. 5 
73 .8 
65. 1 
6.2 
27 . 17 

8 . 9 
3 .16 
4.2 
12 . 3 
12 .3 
3 .17 
3.13 
3.13 
3.3 
75 .2 
3 .12 
3 .11 


Makefile 
clean- request 
genpim.pl 
gf . V 
gf .pirn 

gf . power . tab . top 
gf bit .pla 
gfbyt.V 
gftop.V 
pimlib.pl 

euterpe/verilog/bsrc/gt BOM 75.0 

. checkoutrc 

2gtlb.ut 

3gtltgtlb.ut 

Makefile 

c lean- request 

genpim.pl 

genpipedat .pi 

genptab.pl 

gent st .pi 

gt .V 

gt . power . tab . top 
gt_control . pirn 
gt_driver .V 
gtdone .pla 
gtinstantiate . h 
gtrdy .pla 
gt snake. V 
gtsnakemuxctl . pla 
gtspmatchearly . Veqn 
gtspmatchlate . Veqn 
gtwe . Veqn 
pimlib.pl 


euterpe/verilog/bsrc/hc BOM 90 . 0 

. checkoutrc 
Makefile 
clean- request 
genpimO .pi 
genpiml .pi 
gent st .pi 
hc.V 
hc.h 
he .ut 

hcO . power . tab . top 
he 0_cont rol . p im 
hcl . power . tab . top 
hcl_control . pirn 
hc__brresp.pla 
hc_cmp6 . V 
hc_control . pirn 
hc_device.V 
hc_driver. V 
hc_error . Veqn 
hc_f ifo8.V 
hc_f if o8ctrl . Veqn 
hc_ostate.pla 
hc_parse . Veqn 
hc_jprbctrl . pla 
hc_rxcrc . Veqn 
hc_sadrsel . Veqn 
hc_sdecode . Veqn 
hc_sid. Veqn 
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3 . 4 hc_tagmatch . V 
3 . 2 hc_txcrc . Veqn 
13.1 hcinstantiate.h 

27.4 pimlib.pl 

17.6 power . tab. local 

Dir euterpe/verilog/bsrc/hz BOM 22.0 

4.2 . checkout rc 

1.5 Makefile - 

4.4 clean- request 

4.5 genpim.pl 
1.13 hz.V 

9.6 hz.pim 

10.5 hz . power . tab . top 
1.1 hz . ut 

4 . 1 hz_control . pirn 

1.3 hzmatch.V 

1.7 hztester.V 

1.2 hztester.h 

4.2 pimlib.pl 

4.1 power . tab. local 

Dir euterpe/verilog/bsrc/icc BOM 29.0 

15.1 .checkoutrc 

1.4 Makefile 

3.3 genpim.pl 
1.32 icc.V 

2.5 icc.h 

19.4 ice .power .tab. top 

16.7 icc_control .pirn 

15.5 iccinhif e . Veqn 

1.8 iccxci6.Veqn 
1 . 9 iccxci7 .Veqn 
3.5 pimlib.pl 

Dir euterpe/verilog/bsrc/if e BOM 54 . 0 

18.1 .checkoutrc 

4.2 1 . ut 
1.11 Makefile 

18.4 clean-request 

15 . 5 genpim.pl 
1.2 if.h 

1.8 ifbr.tst 

1.38 ife.v 

4 0,3 if e. power .tab. top 

15.13 ife_control.pim 

1.4 iffree.tst 
1.4 iffrees.tst 

1.4 ifhold.tst 

1 . 8 ifpcselil . Veqn 

2.7 ifrst.tst 

1 . 2 if wntdi3 . Veqn 

1 . 10 if wntdi4 . Veqn 

28.1 ifwntdi6 .Veqn 

15.2 pimlib.pl 

15.1 power . tab. local 

Dir euterpe/verilog/bsrc/io BOM 38.0 

9.5 . checkoutrc 
1.16 Makefile 

9 . 8 clean- request 
8.5 genpim0.pl 

8 . 5 genpiml .pi 

24.6 ioO .power . tab. top 
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22.7 ioO_control .pirn 
24.6 iol .power . tab . top 
2 2.4 iol_control .pirn 

31.1 ioJbuf_8.V 

6.3 io_ififo.V i 

6.1 io_iphase.Veqn 

6.1 io_ofifo.V 

6 . 1 io ophase . Veqn 

6.2 io_scioff_6 .V 
6.1 io_scioff_9.V 

3.1 iocount.pla 

3 . 2 iodrive . V 

3.1 iofs.Veqn I 

3.10 iorate.V j 

4.8 pimlib.pl 

7.3 power. tab. local 

Dir euterpe/verilog/bsrc/iq BOM 60.0 

22.3 . checkout rc 

12.2 l.ut j: 
1.3 7 Makefile ]' 
24.6 clean- request j 

2 0.8 genpim.pl 

1.3 0 iq.V 

5 0.4 iq. power . tab. top 

20.16 iq_control . pirn 

2.7 iqbr.tst 
1.10 iqfree.tst 

1.8 iqfree5.tst 

1.10 iqhold.tst 

1.11 iqhold5.tst 

1 . 1 iqholdq2 . Veqn 

1 . 5 iqholdqq . Veqn 
3 . 1 iqpredq4 . Veqn 

9.4 iqrst.tst 

20.4 pimlib.pl 

20.2 power, tab. local 

Dir euterpe/verilog/bsrc/lt BOM 83.0 

56.1 .checkoutrc 
3.29 Makefile 
56.6 clean-request 

56.2 genpim.pl 
56.1 genptab.pl 

3.68 lt.V j 

68.8 It .power . tab. top 
56.12 lt_control .pirn 

7 . 7 ltstldenbl . Veqn 
5 6.13 pimlib.pl 

Dir euterpe/verilog/bsrc/mc BOM 63.0 

17.3 . checkoutrc 
1.19 Makefile 

17 . 10 clean- request 

13.10 genpim.pl 

1.22 mc.V 

3 8.6 mc. control . obs 

4 8.4 mc . control .pirn 
4 8.4 mc.dataHigh.pim 
4 8.3 mc . dataLow . pirn 
6.24 mc.pim 

3 7.7 mc .power . tab. top 

14.31 mc^xluc.V 

28.3 mc_xlud.V 

1.6 mcacc8,V 
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1.5 mcaddbyt.V 

1.1 mcadf32.V 
1.11 mcalu64.V 

1.2 mccla.V 
13.2 piralib.pl 

16.2 power . tab . local 

Dir euterpe/verilog/bsrc/mg BOM 48-0 

14.3 lstr.ut 
1.31 Makefile 
1 . 1 dee . in 

1 . 1 dco . in 

1.3 mg . h 

8 . 25 mgrst . tst 

1.23 rslt.tst 

10.10 str.tst 

Dir euterpe/verilog/bsrc/mst BOM 34.0 

13.2 . checkoutrc 

I. 15 Makefile 

13.8 clean- request 

II. 6 genpira.pl 
20 . 1 msaccl6 . V 
1.1 msadf32.v 
1.5 msbooth.V 
20.1 mscsaddl6a.V 
20.1 mscsaddl6b.V 
20.1 mscsaddl6e.V 

1.3 mshotc.V 
20 . 1 mshotca. V 
20.1 msinl6a.V 
20.1 msinl6b.V 
20.1 msrcdl6.V 
20.1 msrcdl6a.V 
20.1 msrcdl6b.V 
1.11 mst.V 
2.17 mst.pira 

2 3.7 mst . power . tab . top 

1.1 mstop.V 
11.1 pimlib.pl 

Dir euterpe/verilog/bsrc/nb BOM 111.0 

4 6.5 . checkoutrc 

1.43 Makefile 

1 . 4 README 

46.7 clean-request 

31 . 14 genpim.pl 

52 . 5 genptab.pl 

1.4 muxffl7_l.v 
1.4 muxffl7_4.V 

1.2 muxffl7_5.V 
1.69 nb.V 

31.10 nb.h 

82.7 nb. power. tab. top 

31.4 nb. toplevel.ut 

14.11 nb.ut 

3 8.33 nb_control.pim 

88.9 nb_mid . pim 
88.13 nb_top.pim 
9.19 nbal6x64.tpl 
31.19 nbctrl.Veqn 
9.19 nbd3 2x64.tpl 
1.13 nbfq.V 

44.4 nbf qcount .pla 

1.3 nbf qprienc.pla 
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1,5 nbfqslice .pla 

44,3 nbfulllp.pla 

90.1 nbgotone . V 

90.1 nbgotoneslice . Veqn 

12.2 nbholdof f .pla 

68.1 nbholdof f 3 .pla 
1.13 nbperiph.V 
1.13 nbpq.V 

1.3 nbpqhelper .pla 

1 . 3 nbpqptrbitO . Veqn 

1.5 nbpqptrslice . Veqn 

7 . 4 nbprbarb . Veqn 

7 . 2 nbprbcount . pla 

1 . 5 nbrq . V 

1 . 3 nbrqptrbitO . Veqn 
1 . 3 nbrqptrslice . Veqn 
1.51 nbtester.V 

1.8 nbtester.h 

8.3 nbvd.pla 
15.6 nbwe . Veqn 
31.13 pimlib.pl 

Dir euterpe/verilog/bsrc/nb/rf BOM 5.0 

1.4 Makefile 
1.1 rf.ut 
1.4 rflrlw.V 

1.1 rf Irlwl6wx64b.h 

1.1 rf Irlw32wx64b.h 

1.1 rf tester. v 

1.1 rf tester. h 

Dir euterpe/verilog/bsrc/periph BOM 8.0 

1.6 Makefile 
1 . 1 README 

1.1 p . ut 

3.2 Sptest.ut 

Dir euterpe/verilog/bsrc/rf BOM 3 . 0 

1.2 l.tst 

1.7 Makefile 

1.3 dor f spy 

1.2 drvchk.V 

1.6 rf_l.V 
1 . 5 rf _5 . V 

1 . 3 rf _dec . Veqn 
1 . 2 run . V 

1 . 2 spy . V 

Dir euterpe/verilog/bsrc/rg BOM 106.0 

60.2 .checkoutrc 

14.1 lbr.ut 

14.2 le.ut 

14 . 3 lmul . ut 
1.48 Makefile 

60 . 5 clean-request 

19.12 genpim.pl 

82.1 genptab.pl 
19.23 pimlib.pl 

19.2 power . tab. local 
29.15 rg.V 

82.12 rg.pim 

7 9.7 rg. power. tab. top 

6 7.3 rg_control . pirn 

1.11 rgcr.V 
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1.20 rgdp.V 
1.7 rgimm.V 
1.28 rgpc . V 

52 . 1 rgplro .pla 
9.24 rgrst.tst 

1.15 rslt.tst 

Dir euterpe/verilog/bsrc/rgxmit BOM 3 3.0 

1.4 . checkoutrc 

1.4 Makefile 

8.4 clean-request 

1.2 genpim.pl 
1.1 pimlib.pl 

1 . 1 power . tab . local 

1 . 3 rgpcbrr7 . Veqn 

1 . 3 rgwewk . Veqn 

1.21 rgxmit.V 

19.4 rgxmit .power . tab. top 
1.11 rgxmi t_cont rol . pirn 

Dir euterpe/verilog/bsrc/sr BOM 57.0 

24.5 .checkoutrc 
1.20 Makefile 

26.6 clean- request 

16 . 11 genpim .pi 
27.5 genptab.pl 

16 . 12 pimlib .pi 
2.30 sr.V 

3.4 sr.h 
51.4 sr. pirn 

3 9.7 sr . power . tab . top 

1.2 sr_cla.Veqn 
16.21 sr_control .pirn 
1 . 9 sr_dr iver . V 

3 . 3 sr_eventl6 . Veqn 

3 . 4 sr_eventreg . v 
16.4 sr_eventreg .pirn 
3.6 sr_evmaskl6 . V 

41.2 sr_hcevent . V 
1.3 sr_inc4.pla 

I . 3 sr_inc4a .pla 
2 . 4 srjnatch . V 

II . 1 sr_mchold. Veqn 
3 . 3 sr_radecode . pla 
1.3 sr_timer.V 
16.2 sr_timer.pim 

3 . 2 sr_wadecode . pla 

Dir euterpe/verilog/bsrc/tst BOM 96.0 

13.2 le.ut 

13.3 libr.ut 

13.2 liss.ut 

13.3 11. ut 
13.2 lpc.ut 

13.1 lq.ut 
13 .1 lstr.ut 
1.24 Makefile 
1.9 br.tst 
1.73 drvchk.v 
(1.72) 

70.2 ic.tst 
6.33 job.tst 
1.11 rslt.tst 
1.28 rst.tst 

1.16 spy.V 
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3 . 7 

tstgen 

6.31 

tbvl . L. fc> L. 

3.1 

vervars 

3 . 4 


3.1 

vlwire 

Dir 

euterpe/verilog/bsrc/uu 

79.2 

. checkoutrc 

25.1 

l.ut 

25 .1 

le.ut 

25.2 

limm.ut 

25.2 

limmpc .ut 

25.1 

liss .ut 

25.1 

lnb.ut 

25 . 1 

lpc .ut 

1.74 

Makefile 

2.13 

br . tst 

78.8 

clean- request 

131.7 

evblm . prio 

(131.6) 


68.13 

genpim.pl 

68 . 11 

pimlib.pl 

81.1 

power . tab . local 

125.3 

sswap . tst 

123 .3 

uu- local .obs 

1.164 

uu.v 

(1.163) 


1.37 

uu.h 

119.4 

uu . power . tab . top 

68.32 

uu_control .pirn 

1.22 

uubruv . tdcd 

1.13 

uubruw . Veqn 

1.20 

uubypltncyuv . tdcd 

1.4 

uuchkdstr3 . Veqn 

1.10 

uuchkdstuw. Veqn 

112.1 

uucmp2rn.V 

1.10 

uudstselut . tdcd 

1.9 

uuf ree . tst 

1.15 

uuhold. tst 

1 . 19 

uuholduu . Veqn 

1 .20 

uuimmpc .tst 

1.32 

uuimmpcut . tdcd 

24 .12 

uuimmus . tdcd 

1.14 

uuisdstuv. tdcd 

1.1 

uuisdstuv split 

1.24 

uuissrcur . tdcd 

28 .9 

uu j obi s tux . Veqn 

63 .12 

uumemuv . tdcd 

8 . 13 

uumic . tst 

8.12 

uumicut . tdcd 

9.8 

uumicuu. tdcd 

112 . 3 

uuovrlyregreg . V 

156.2 

uuovrlysrcdstcyl .pirn 

36.15 

uuprblmf rz . Veqn 

108 .6 

uuprblmr 0 . Veqn 

(108 .5) 


108.6 

uuprblmr 1 0 . Veqn 

(108 .5) 


50 .8 

uuprblmr 11 .Veqn 

(50.7) 


50. 8 

uuprblmrl2 . Veqn 

(50.7) 


60.10 

uuprblmr 13 . Veqn 

(60.9) 


50 .10 

uuprblmr 5 . Veqn 

(50.9) 


50.1 

uuprblmr 6 . Veqn 
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107 . 10 

uuprblmr7 . Veqn 

(107 .9) 


50.13 

uuprblmr8 . Veqn 

(50.12) 


61.14 

uuprblmr9.Veqn 

(61.13) 


32 .14 

uuprblmup . Veqn 

50.16 

uuprblmwm . Veqn 

(50 . 15) 


14 . 3 3 

uupreemuq . Veqn 

1.2 

uupsi .pla 

8.3 

uurbuu . Veqn 

15.11 

uursltbypcuu . Veqn 

1.20 

uursltbypuu . Veqn 

28 . 9 

uursrvd. tdcd 

15.26 

uurst . tst 

53 .2 

uurstuq.pla 

76.4 

uuruptrl2 . Veqn 

84 . 6 

uusteput .pla 

84 . 8 

uustepuu.pla 

1.16 

uuthruus . tdcd 

1 . 11 

uuthruut . Veqn 

1 . 2 

uuwew j . Veqn 

156 . 3 

uuxlutrap . V 

156.2 

uuxlutrap . pirn 

Dir 

euterpe/verilog/bsrc/xlu 

28.2 

. checkout rc 

1.46 

Makefile 

8 . 1 

TODO 

25. 1 

cl . srf 

25.1 

c2 . srf 

26.1 

c3 . srf 

36.1 

clean- request 

25.1 

cs2 . srf 

25 .1 

cs3 . srf 

23 .2 

db_7a . srf 

21.5 

dc_8a . srf 

8.20 

genpim .pi 

22 .4 

misc2 . srf 

22 .3 

misc3 . srf 

8 .19 

pimlib .pi 

35 .1 

power . tab . local 

21.4 

q_9a_7 . srf 

19.14 

route .pi 

33.7 

xl23 .pirn 

40. 1 

xl26 .pirn 

33 .2 

x456 .pirn 

25.1 

xbus . srf 

24.8 

xlu.V 

14.4 

xlu . rape 

35.1 

xlu.nets 

33.1 

xlu.nof lip 

48.2 

xlu . power . tab . top 

17.5 

xlu . rcf 

33 .7 

xlu4 . obs 

39.1 

xlu6 .obs 

41.2 

xlu_add4 .V 

1.16 

xlu_ctrldata . c 

1.2 

xlu_la_r2 . c 

18 .2 

xlu_sr . c 

28 .1 

xlujsr _c3 .dir 

28.3 

xlu_sr_r2 .dir 

28.1 

xlu_sr_r3 . dir 

6.2 

xlu_tr_sl . c 

28 .1 

xlu_tr_sl .dir 

6.2 

xlu tr s2.c 
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28.1 xlu_tr_s2 . dir 

6 . 2 xlu_tr_s3 . c 

26.1 z3.srf 

25.1 zs3.srf 


Dir euterpe/verilog/bsrc/yy BOM 24 . 0 

1.15 Makefile 

1.2 dob2dascii 

2.2 dotestassign 

1.22 tas.pl 

2.1 test.V 

1.1 yy-h 

1.5 yyunasm.V 

1 . 5 yyunasmmnesel . tdcd 

1 . 5 yyunasmmusel . tdcd 

===> running euterpe/verilog/bsrc/ . checkoutrc (Sat Mar 11 01:40:38 PST 
1995) <=== 

pager lisar Id: BOM,V 250.0 1995/03/11 01:37:10 LT raws Exp 
page queued 
starting paged 

for i in at au cc cdio ce eg cj ck cp ctioi ctiod dr drio es gf gt he hz 
ice ife io iq It mst mc nb rg rgxmit sr uu xlu; do \ 
gmake -C ${i} vfiles | | exit; \ 

done 

gmake [1] : Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/at ' 
gmake[lj: "vfiles' is up to date. 

gmake [1]: Leaving directory * /N/auspex6/sl0/chip/euterpe/verilog/bsrc/at 1 
gmake [1]: Entering directory * /N/auspex6/sl0/chip/euterpe/verilog/bsrc/au 1 
gmake[l]: "vfiles' is up to date. 

gmake [1]: Leaving directory " /N/auspex6/sl0/chip/euterpe/verilog/bsrc/au 1 
gmake [1]: Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/cc ' 
gmake [1]: "vfiles' is up to date. 

gmake [1]: Leaving directory " /N/auspex6/sl0/chip/euterpe/verilog/bsrc/cc ' 
gmake [1] : Entering directory 

"/N/auspex6/sl0/chip/euterpe/verilog/bsrc/cdio ' 
gmake [1] : "vfiles' is up to date, 
gmake [1] : Leaving directory 

"/N/auspex6/sl0/chip/euterpe/verilog/bsrc/cdio 1 

gmake [1]: Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/ce ' 
gmake [1] : "vfiles' is up to date. 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/ce ' 
gmake [1] : Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/cg ' 
cat /n/auspex6/sl0/chip/euterpe/proteus/verilog/dxlib/xlib. conf ig 
/n/auspex6/ slO/chip/euterpe/proteus/verilog/dclib/clib . conf ig 
/n/auspex6/sl0/chip/euterpe/proteus/verilog/delib/elib. conf ig > v2e . conf ig 
cp v2e.config clockbias . conf ig 

echo 'lib clockbias = cgclockbias; omit contents clockbias; 1 >> 
clockbias . conf ig 

/n/auspex6/sl0/chip/euterpe/tools/bin/v2e -host Cyclops cgclockbias .v -c 
clockbias . conf ig -o cgclockbias .v2e -y 

/n/auspex6/sl0/chip/euterpe/proteus/verilog/mlib +libext+.v -y 
/n/auspex6/sl0/chip/euterpe/proteus/verilog/dxlib -y 
/n/auspex6/sl0/chip/euterpe/proteus/verilog/dclib -y 
/n/auspex6/sl0/chip/euterpe/proteus/verilog/delib 
V2E 1.0a Mar 11, 1995 01:41:01 

* Copyright Cadence Design Systems Inc. 1990. * 

* All Rights Reserved. Licensed Software. * 

* Confidential and proprietary information which is the * 

* property of Cadence Design Systems Inc. * 
Compiling source file "cgclockbias .v" 

Scanning library directory 

"/n/auspex6/sl0/chip/euterpe/proteus/verilog/mlib" 
Scanning library directory 

T, /n/auspex6/sl0/chip/euterpe/proteus/verilog/dxlib" 
Scanning library directory 

"/n/auspex6/sl0/chip/euterpe/proteus/verilog/dclib" 
Warning! library directory 
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"/n/auspex6/sl0/chip/euterpe/proteus/verilog/mlib" was specified but not 
needed. 

Warning! library directory 

M /n/auspex6/sl0/chip/euterpe/proteus/verilog/dxlib" was specified but not 
needed. 

Warning! library directory 

"/n/auspex6/sl0/chip/euterpe/proteus/verilog/delib" was specified but not 
needed. 

Highest level modules: 
cgclockbias 

Reading configuration file clockbias . conf ig .... 
Processing configuration file 
Translating Verilog source .... 
Writing output to cgclockbias .v2e .... 
0 warnings 0 errors 

End of V2E 1.0a Mar 11, 1995 01:41:14 
echo cgclockbias. v | tr ' 1 1 \012 1 > vfiles 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/cg' 
gmake [1]: Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/cj ' 
gmake [1] : "vfiles' is up to date. 

gmake [1]: Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/cj 1 
gmake [1] : Entering directory " /N/auspex6/sl0/chip/euterpe/verilog/bsrc/ck ' 
gmake [1] : "vfiles" is up to date. 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/ck T 
gmake [1]: Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/cp ' 
gmake [1] : "vfiles' is up to date. 

gmake [1]: Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/cp ■ 
gmake [1] : Entering directory 

"/N/auspex6/sl0/chip/euterpe/verilog/bsrc/ctioi ' 
gmake [1] : "vfiles" is up to date, 
gmake [1] : Leaving directory 

"/N/auspex6/sl0/chip/euterpe/verilog/bsrc/ctioi ' 
gmake [1]: Entering directory 

"/N/auspex6/sl0/chip/euterpe/verilog/bsrc/ctiod' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1}: Leaving directory 

"/N/auspex6/sl0/chip/euterpe/verilog/bsrc/ctiod' 

gmake [1]: Entering directory " /N/auspex6/sl0/chip/euterpe/verilog/bsrc/dr 1 
gmake [1] : "vfiles 1 is up to date. 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/dr ' 
gmake [1] : Entering directory 

" /N/auspex6/sl0/chip/euterpe/verilog/bsrc/drio ' 
gmake [1] : "vfiles 1 is up to date, 
gmake [1] : Leaving directory 

"/N/auspex6/sl0/chip/euterpe/verilog/bsrc/drio' 

gmake [1] : Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/es 1 
gmake [1]: "vfiles 1 is up to date. 

gmake [1] : Leaving directory " /N/auspex6/sl0/chip/euterpe/verilog/bsrc/es ' 
gmake [1] : Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/gf ' 
gmake [1] : "vfiles 1 is up to date. 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/gf 1 
gmake [1] : Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/gt ' 
cat /n/auspex6/sl0/chip/euterpe/proteus/verilog/dif f .h gt.V J /lib/cpp -P 
-C -B | sed -e »/ A $/d'> gt.v.tmp 
mv gt . v . tmp gt . v 

echo gt.v gt snake. v gtspmatchearly . v gtspmatchlate.v gtwe.v gtrdy.v 
gtsnakemuxctl .v gtdone.v | tr ' 1 ' \012' > vfiles 

gmake [1]: Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/gt ' 
gmake [1] : Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/hc ' 
gmake [1] : "vfiles' is up to date. 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/hc ' 
gmake [1] : Entering directory " /N/auspex6/sl0/chip/euterpe/verilog/bsrc/hz " 
gmake [1] : "vfiles" is up to date. 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/hz ' 
gmake [1] : Entering directory 

"/N/auspexS/slO/chip/euterpe/verilog/bsrc/icc ' 
gmake [1] : "vfiles" is up to date. 
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gmake[l]: Leaving directory * /N/auspex6/sl0/chip/euterpe/verilog/bsrc/icc • 
gmake[l]: Entering directory 

VN/auspex6/slO/chip/euterpe/verilog/bsrc/if e ' 
gmake [1] : "vfiles 1 is up to date. 

gmake [1] : Leaving directory ** /N/auspex6/sl0/chip/euterpe/verilog/bsrc/if e ' 
gmake [1] : Entering directory " /N/auspex6/sl0/chip/euterpe/verilog/bsrc/io » 
gmake [1]: "vfiles" is up to date. 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/io 1 
gmake [1] : Entering directory VN/auspex6/slO/chip/euterpe/verilog/bsrc/iq 1 
gmake [1] : "vfiles' is up to date. 

gmake [1] : Leaving directory VN/auspex6/slO/chip/euterpe/verilog/bsrc/iq 1 
gmake [1] : Entering directory VN/auspex6/slO/chip/euterpe/verilog/bsrc/lt 1 
gmake [1] : "vfiles 1 is up to date. 

gmake [1] : Leaving directory /N/auspex6/sl0/chip/euterpe/verilog/bsrc/lt 1 
gmake [1] : Entering directory 

VN/auspex6/slO/chip/euterpe/verilog/bsrc/mst ' 
gmake [1] : "vfiles' is up to date. 

gmake [1] : Leaving directory *"/N/auspex6/slO/chip/euterpe/verilog/bsrc/mst ' 
gmake [1] : Entering directory VN/auspex6/slO/chip/euterpe/verilog/bsrc/mc ' 
gmake [1] : "vfiles' is up to date. 

gmake [1] : Leaving directory VN/auspex6/slO/chip/euterpe/verilog/bsrc/mc ' 
gmake [1] : Entering directory VN/auspex6/slO/chip/euterpe/verilog/bsrc/nb' 
gmake [1] : "vfiles 1 is up to date. 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/nb' 
gmake [1] : Entering directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/rg ' 
gmake [1] : "vfiles' is up to date. 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/verilog/bsrc/rg 1 
gmake [1] : Entering directory 

VN/auspex6/slO/chip/euterpe/verilog/bsrc/rgxmit 1 
gmake [1] : ""vf lies' is up to date, 
gmake [1] : Leaving directory 

VN/auspex6/slO/chip/euterpe/verilog/bsrc/rgxmit ' 

gmake [1] : Entering directory "* /N/auspex6/sl0/chip/euterpe/verilog/bsrc/sr 1 
gmake [1] : "vfiles' is up to date. 

gmake [1]: Leaving directory VN/auspex6/slO/chip/euterpe/verilog/bsrc/sr 1 
gmake [1]: Entering directory VN/auspex6/slO/chip/euterpe/verilog/bsrc/uu 1 
cat /n/auspex6/sl0/chip/euterpe/proteus/verilog/dif f .h uu.V | /lib/cpp -P 
-C -B | sed -e '/ A $/d'> uu.v.tmp 
rav uu . v . tmp uu . v 

cat uuprblmrO . Veqn | /lib/cpp -P -C -B > uuprblmrO . esp . tmpl 
cat uuprblmr5 . Veqn j /lib/cpp -P -C -B > uuprblmrS . esp . tmpl 
cat uuprblmr7 . Veqn j /lib/cpp -P -C -B > uuprblmr7 . esp. tmpl 
egrep ,A //| A /\*.*\*/' < uuprblmrS . esp . tmpl > uuprblmrS . esp. comments 
egrep ,A //| A /\*.*\*/' < uuprblmrO . esp . tmpl > uuprblmrO . esp. comments 
cat uuprblmr8 . Veqn | /lib/cpp -P -C -B > uuprblmr8 . esp . tmpl 
/n/auspex6/sl0/chip/euterpe/tools/bin/veqn uuprblmrO . esp . tmpl > 
uuprblmrO . esp . tmp 2 

/n/auspex6/sl0/chip/euterpe/ tools/bin/ veqn uuprblmrS . esp. tmpl > 
uuprblmrS . esp . tmp2 

egrep ,A //]V\*.*\*/' < uuprblmr7 . esp . tmpl > uup rblmr 7 . esp. comments 
cat uuprblmr9. Veqn | /lib/cpp -P -C -B > uuprblmr9 . esp. tmpl 
/n/auspex6/ si O/chip/euterpe/ tools/bin/ veqn uuprblmr7 . esp . tmpl > 
uuprblmr7 . esp . tmp2 

cat uuprblmrlO . Veqn J /lib/cpp -P -C -B > uuprblmrlO . esp . tmpl 
egrep ,A //| A /\*-*\*/' < uuprblmr9 . esp . tmpl > uup rblmr 9 . esp . comments 
cat uuprblmrll. Veqn J /lib/cpp -P -C -B > uuprblmrll . esp . tmpl 
/n/auspex6/sl0/chip/euterpe/tools/bin/veqn uup rblmr 9 . esp . tmpl > 
uuprblmr9 . esp . tmp 2 

egrep ,A //| A /\*.*\*/' < uuprblmrlO . esp . tmpl > uuprblmrlO . esp . comments 
cat uuprblmrl2 . Veqn | /lib/cpp -P -C -B > uuprblmrl2 . esp . tmpl 
/n/auspex6/sl0/chip/euterpe/tools/bin/veqn uuprblmrlO . esp . tmpl > 
uuprblmrl 0 . esp . tmp2 

cat uuprblmrl3 . Veqn | /lib/cpp -P -C -B > uuprblmrl3 . esp . tmpl 

egrep ' A // | A /\* . *\*/ 1 < uuprblmrl3 . esp . tmpl > uuprblmrl3 . esp . comments 

egrep ,A //| A /\*.*\*/' < uuprblmrl2 . esp . tmpl > uuprblmr 12 . esp . comments 

cat uuprblmwm . Veqn | /lib/cpp -P -C -B > uup rb lmwm . esp . tmpl 

egrep ,A //| A /\*.*\*/' < uuprblmwm. esp. tmpl > uuprblmwm. esp . comments 

/n/auspex6/sl0/chip/euterpe/tools/bin/veqn uuprblmrl2 .esp. tmpl > 
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uuprblmrl2 . esp . tmp2 

/n/auspex6/sl0/chip/euterpe/tools/bin/veqn uuprblmrl3 .esp. tmpl > 
uuprblmrl3 . esp . tmp2 

/n/auspex6/sl0/chip/euterpe/tools/bin/veqn uuprblmwm. esp. tmpl > 
uuprblmwm . esp . tmp2 

egrep ,A //| A /\*-*\*/' < uuprblmrll . esp . tmpl > uuprblmrll . esp . comments 
egrep 'V/| A /\*.*\*/' < uuprblmr8 . esp . tmpl > uuprblmr8 . esp. comments 
/n/auspex6/sl0/chip/euterpe/tools/bin/veqn uuprblmrll . esp. tmpl > 
uuprblmrll . esp . tmp2 

/n/auspex6/sl0/chip/euterpe/tools/bin/veqn uuprblmr8 . esp . tmpl > 
uuprblmrS . esp . tmp2 

OCTTOOLS=/n/auspex6/slO/chip/euterpe/tools/vendor/octtools 
/n/auspex6/sl0/chip/euterpe/ tools/vendor /octtools/bin/misll -x -c 
" read_eqn uuprblmrO . esp . tmp2 ; write_pla uuprblmr 0 . esp . tmp3 " 
sed -e 1 s! //!#//!' -e ' s ! A* ! #/\* ! ' < uuprblmrO . esp . comments > 
uuprblmr 0 . esp 

cat uuprblmrO . esp . tmp3 >> uuprblmrO . esp 

rm - f uuprblmrO . esp . tmpl uuprblmrO - esp . tmp2 uuprblmrO . esp . tmp3 
uuprblmrO . esp . comments 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu < uuprblmrO . esp -eeat 
-Dcheck -v irred 

# PLA is (stdin) with 4 inputs and 2 outputs 

# ON-set cost is c=3(3) in=3 out =3 tot =6 

# OFF-set cost is c=4(4) in=6 out=7 tot=13 

# DC-set cost is c=0(0) in=0 out=0 tot=0 

# Input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF-SET are disjoint 
DC-SET and OFF-SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 
OPTS="grep DOESPRESSO_OPTS : < uuprblmrO . esp | \ 

sed -e ' s ! A # / . *DOESPRESSO_OPTS : 1 J 1 -e 'slX*/!!'*"; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $OPTS 
uuprblmrO . esp 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu . . . 
Running /n/auspex6/sl0 /chip/euterpe/tools/bin/espresso . mu -Dso_both. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu on output of 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -Dso_both. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu -Dopo. . . 
Reg: tot=6 cube=2 max-AND-f anin=3 max-0R-fanin*2 max-fanins3 

Sob: tot=6 cube=3 max-AND-f anin=3 max- OR- f anin=2 max-fanin=3 

SobReg: tot=6 cube=2 max -AND- f anin=3 max- OR- f anin=2 max-fanin=3 
Opo: tot=6 cube =3 max-AND-f anin= 3 max -OR- f anin=2 max- fan in =3 

=> Espresso provides the best solution. 
Output in uuprblmrO . doe sp. out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits < uuprblmrO . doesp . out > 
uuprblmrO . optesp . tmp 

rm - f uuprblmrO . doesp . out uuprblmrO . doesp . opo \ 

uuprblmrO . doesp . sob uuprblmrO . doesp . reg uuprblmrO . doesp . sobreg 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat "grep PLAT_OPTS : < 
uuprblmrO . esp | \ 

sed -e ' s! A #/.*PLAT_OPTS: M ' -e 's!\*/!!' * uuprblmrO . optesp . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat : opening Espresso- format input 
file ~ uuprblmrO .optesp. tmp 1 for reading 

/n/auspex6/sl0/chip/euterpe/ tools/bin/plat : parsing PLA file and building 
datastructures . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : PLA has 4 inputs 2 outputs 2 
pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : creating Planet input in 

"uuprblmrO. optesp. planet* . . . 

mv uuprblmrO .optesp. planet uuprblmrO .optesp 

rm -f uuprblmrO .optesp. tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet "grep PLANE T_OPTS : < 
uuprblmrO .optesp | \ 

sed -e 1 s! *##/. * PLANE T_OPTS : !J ' -e 's!\*/!!' " -maxFanin 17 
uuprblmrO .optesp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Opening Espresso- format 
input file "uuprblmrO . optesp ' 
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/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : Creating Verilog output file 
v uuprblmrO . v ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Pirn output file 
"uuprblmrO .pirn' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Parsing PLA file and 
building datastructures . . . 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet Version 0.1.28 Tue Feb 28 
14:41:06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : #tt Input phase is not 
specified. 

/n/auspex6 /slO/chip/euterpe/ tools/bin/planet : PLA has 4 inputs 2 outputs 2 
pterins 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Phase 11 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Making netlist... 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Verilog file 
"uuprblmrO . V . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Pirn file 
"uuprblmrO .pirn' . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum primary input 
fanout: 1 [oooRO] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanin: 3 
[pterm 2] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : This pterm drives a 
maximum output plane fanin of: 2 [prblmCdRl<0>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanout: 

1 [pterm 2] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum output plane fanin: 

2 [prblmCdRl<0>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 2 pirn rows produced 
OCTTOOLS=/n/auspex6/slO/chip/euterpe /tools /vendor /octtools 
/n/auspex6/sl0/chip/euterpe/ tools/vendor /octtools/bin/misll -x -c 
"read_eqn uuprblmr7 . esp . tmp2 ; write_pla uuprblmr7.esp.tmp3" 
"uuprblmr7.esp.tmp2", line 137: node ■ prblmCdR8_3 1 does not fanout 
"uuprblmr7.esp.tmp2", line 137: node ' prblmCdR8_4 ■ does not fanout 
sed -e ' s!// !#//!' -e 1 s i /\* 1 #/\* ! 1 < uuprb lmr 7 . esp. comments > 
uuprblmr7 . espdc 

cat uuprblmr7 . esp . tmp3 >> uuprblmr7 . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -eeat -Dcheck -v irred 
uuprblmr7 . espdc 

# PLA is uuprblmr7. espdc with 22 inputs and 6 outputs 

# ON-set cost is c=24(24) in=71 out-24 tOt=95 

# OFF-set cost is c=55(55) in=158 out=65 tot=223 

# DC-set cost is c=0(0) in=0 out=0 tot=0 

# Input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF -SET and DC-SET is the universe 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -Draapdc uuprblmr7 .espdc 
> uuprblmr7 . espphless 

sed -e '/Input phase is not/d' uuprblmr7 . espphless > uuprblmr7 . esp 
#planet uses 1st of these 

rm -f uuprblmr7.esp.tmpl uuprblmr7 . esp . tmp2 uuprblmr7 . esp . tmp3 
uuprb lmr 7 . esp . comments uuprb lmr 7 . espdc uuprblmr7 . espphless 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu < uuprblmr7 . esp -eeat 
-Dcheck -v irred 

# PLA is (stdin) with 21 inputs and 6 outputs 

# ON-set cost is c=15(15) in=41 out=13 tot=54 

# OFF-set cost is c=48(48) in=142 out=53 tot=195 

# DC-set cost is c=3(3) in=7 out =9 tot=16 

# Input phase is not specified. 
ON- SET and DC-SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 
OPTS=~grep DOES PRESS 0_0 PT S : < uuprblmr7 . esp | \ 
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max - OR - f anin= 4 
max - OR - f anin= 4 
max-OR- f anin=4 


max-fanin=4 
max- fanin=4 
max-fanin=4 
max- f anin=4 


sed -e ' SI A #/ . *DOESPRESSO_OPTS : ! ! ' -e ' s!\*/!!»"; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $OPTS 
uuprblmr7 . esp 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu. . . 
Running /n/auspex6 /slO/chip/euterpe/ tools/bin/espresso .mu -Dso_both. . . 
Running /n/auspex6 /slO/chip/euterpe/ tools/bin/espresso . mu on output of 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -Dso_both. . . 
Running /n/auspex6 /slO/chip/euterpe/ tools/bin/espresso . mu -Dopo 
Reg: tot=44 cube=14 max- AND- f anin=3 max-OR- fanin= 4 

Sob: tot=44 cube=14 max-AND- f anin=3 

SobReg: tot=44 cube=14 max-AND- fan in- 3 
Opo: tot=44 cube=14 max-AND- fanin =3 

=> Espresso provides the best solution. 
Output in uuprblmr7 . doesp . out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits 
uuprblmr7 . optesp. tmp 

rra -f uuprblmr7 .doesp. out uuprblmr7 . doesp . opo \ 

uuprblmr7 . doesp . sob uuprblmr7 . doesp . reg uuprblmr7 . doesp . sobreg 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat "grep PLAT_OPTS : < 
uuprblmr7 . esp j \ 

sed -e 's! ^#/.*PLAT_OPTS: ! ! ' -e 'b'\*/!!' 
/n/auspex6/sl0/chip/euterpe/ tools/bin/plat : 
file " uuprblmr 7 . optesp . tmp 1 for reading 
/n/auspex6/sl0/chip/ euterpe/tools/bin/plat : 
datastructures . . . 

/n/auspex6/sl0/chip/euterpe/ tools/bin/plat : 
pterins 

/n/auspex6/sl0/chip/ euterpe/tools/bin/plat : 
"uuprblmr 7 .optesp. planet 1 . . . 

mv uuprblmr 7 . optesp . planet uuprblmr 7 . optesp 
rm - f uuprblmr7 . optesp . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet "grep PLiANET_OPTS : 
uuprblmr 7 . optesp | \ 

sed -e ' s! A ##/.*PLANET_OPTS: ! ! 1 -e 'Sl\*/l! 
uuprblmr 7 . optesp 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
input file "uuprblmr 7 . optesp 1 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
"uuprblmr 7 . v ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 
"uuprblmr 7 .pirn 1 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
building datastructures... 

# /n/auspex6/ slO/chip/euterpe/ tools/bin/planet Version 0.1.2 8 Tue Feb 2 8 
14:41:06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

/n/auspex6/ slO/chip/euterpe/ tools/bin/planet : 
specified. 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
14 pterms 

/n/auspex6 /si 0/chip/euterpe/ tools/bin/planet : 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 
/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
"uuprblmr7.V . . . 

/n/auspex6/ slO/chip/euterpe/tools/bin/planet : 
"uuprblmr 7 .pirn 1 . . . 

/n/auspex6/ slO/chip/euterpe/tools/bin/planet : 
fanout: 5 [eta0R17] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 
[pterm 1] 

/n/auspex6/ slO/chip/euterpe/tools/bin/planet : 
maximum output plane fanin of: 3 [swpWrtCnf IctlfWrt] 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanout: 
1 [pterm lj 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum output plane fanin: 
4 CtCdWrtRdCnflctIfRdR8<0>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 10 pirn rows produced 


uuprblmr7 . doesp . out 


" uuprblmr 7 . optesp . tmp 
opening Espresso- format input 

parsing PLA file and building 

PLA has 21 inputs 6 outputs 14 

creating Planet input in 


" -maxFanin 17 
Opening Espresso- format 
Creating Verilog output file 
Creating Pirn output file 
Parsing PLA file and 


## Input phase is not 

PLA has 21 inputs 6 outputs 

Phase 111111 
Making netlist. . . 
Writing Verilog file 

Writing Pirn file 

Maximum primary input 

Maximum input plane fanin: 3 

This pterm drives a 
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OCTTOOLS=/n/auspex6/slO/chip/euterpe/ tools /vendor /octtools 

/n/auspex6/sl0/chip/euterpe/tools/vendor/octtools/bin/misll -x -c 

" read_eqn uuprblmr5 . esp . tmp2 ; write_pla uuprblmrS . esp . tmp3 " 

M uuprblmr5 . esp . tmp2" , line 186: node » ldUseFailHigherPrioThanlnDcTggl 0 ' 

does not fanout 

"uuprblmr5 . esp . tmp2" , line 186: node r prblmCdR6_3 1 does not fanout 
"uuprblmrS . esp. tmp2" , line 186: node 'prblmCdR6_4 ' does not fanout 
sed -e 's! //!#//!' -e 1 s I /\* ! #/\* ! 1 < uuprblmrS . esp. comments > 
uuprblmr5 . espdc 

cat uuprblmrS . esp . tmp3 » uuprblmr5 . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -eeat -Dcheck -v irred 
uuprblmrS . espdc 

# PLiA is uuprblmrS .espdc with 11 inputs and 4 outputs 

# ON-set cost is c=38(38) in=228 out =3 8 tot=266 

# OFF-set cost is c=22(22) in=60 out=29 tot=89 

# DC-set cost is c=0(0) in=0 out=0 tot=0 

# Input phase is not specified. 
ON- SET and DC -SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -Dmapdc uuprblmrS .espdc 
> uuprblmrS . espphless 

sed -e '/Input phase is not/d' uuprblmrS . espphless > uuprblmrS . esp 
#planet uses 1st of these 

rm -f uuprblmrS . esp. tmpl uuprblmrS . esp . tmp2 uuprblmr5 . esp . tmp3 
uuprblmrS . esp .comments uuprblmrS . espdc uuprblmrS . espphless 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu < uuprblmrS . esp -eeat 
-Dcheck -v irred 

# PLA is (stdin) with 10 inputs and 4 outputs 

# ON-set cost is c=35(35) in=219 OUt=35 tOt=254 

# OFF-set cost is c=20(20) in=55 out=25 tot=80 

# DC-set cost is c=l(l) in=2 out=0 tot=2 

# Input phase is not specified. 
ON-SET and DC-SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 
OPTS="grep DOES PRE S SO_OPTS : < uuprblmrS . esp | \ 

sed -e 1 s ! A #/ . * DOES PRE SSO_OPTS : ! J 1 -e »Si\*/!!''; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $0PTS 
uuprblmrS . esp 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu -Dso_both. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu on output of 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -Dso_both. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -Dopo. .. 
Reg: tot=3 0 cube=9 max- AND- f anin=7 max-OR-f anin=7 max-fanin=7 

Sob: tot=4 3 cube=8 max- AND- f anin=7 max-OR- f anin=3 max-fanin=7 

SobReg: tot=3 6 cube=7 max- AND- f anin=7 max-OR-f anin=3 max-f anin=7 
Opo: tot=34 cube=7 max- AND- f anin=7 max-OR-f anin= 3 max-fanin=7 

=> Espresso provides the best solution. 
Output in uuprblmrS .doe sp .out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits < uuprblmrS . doesp . out > 
uuprblmrS . optesp . tmp 

rm -f uuprblmrS .doesp. out uuprblmrS . doesp. opo \ 

uuprblmr5 . doesp . sob uuprblmrS . doesp . reg uuprblmrS . doesp . sobreg 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat ~grep PLAT_0PTS: < 
uuprblmrS .esp | \ 

sed -e ' s! A #/.*PLAT_0PTS: ! ! ' -e 1 s!\*/J!' " uuprblmrS . optesp . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat : opening Espresso- format input 
file "uuprblmrS .optesp . tmp 1 for reading 

/n/auspex6 /slO/chip/euterpe/ tools/bin/plat : parsing PLA file and building 
datastructures . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : PLA has 10 inputs 4 outputs 9 
p terms 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : creating Planet input in 
"uuprblmrS . optesp. planet 1 . , . 
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mv uuprblmr 5 .opt esp. planet uuprblmr5 . optesp 
rm - f uuprblmr5 . optesp . tmp 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet 
uuprblmr5 . optesp | \ 

sed -e 's! *PLANET_OPTS : ! ! ' -e 's!\*/!!' 
uuprblmr 5 . optesp 

/n/auspex6/sl0/chip/euterpe/ tools /bin/planet : Opening Espresso- format 
input file * uuprblmr 5 . optesp ' 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
"uuprblmr 5 . V 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : Creating Pirn output file 
"uuprblmr5 . pirn 1 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Parsing PLA file and 
building datastructures. . . 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet Version 0.1.28 Tue Feb 28 
14:41:06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

/n/auspex6/sl0/ chip/ euterpe/ tools /bin/planet : 
specified. 

/n/auspex6/ slO/ chip/ euterpe/ tools/bin/planet : 
9 pterms 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
/n/auspex6/ slO/chip/euterpe/ tools/bin/planet : 
/n/auspexS/ slO/chip/euterpe/ tools/bin/planet : 
augAccTypR5<l> is not used 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : WARNING: Input 
augAccTypR5<0> is not used 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 
"uuprblmrS . V . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Pirn file 
" uuprblmr 5 .pirn ' . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 
fanout: 3 [tau] 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
[pterm 8] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 
maximum output plane fanin of: 5 [prblmCdM2R6<l>] 
/n/auspex6/sl0/chip/euterpe/tools/biri/planet : Maximum input plane fanout: 
2 [pterm 6] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum output plane fanin: 
7 [prblmCdM2R6<0>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 5 pirn rows produced 
OCTTOOLS=/n/auspex6/slO/chip/euterpe/tools/vendor/octtools 
/n/auspex6/sl0/chip/euterpe/tools/vendor/octtools/bin/misll -x -c 
" read_eqn uuprblmrll . esp . tmp2 ; write_pla uuprblmrll . esp . tmp3 11 
sed -e 's!// :#//]' -e 1 s ! A* I #/\* ! ' < uuprblmrll. esp. comments > 
uuprblmrll . espdc 

cat uuprblmrll . esp . tmp 3 » uuprblmrll . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -eeat -Dcheck -v irred 
uuprblmrll . espdc 

# PLA is uuprblmrll .espdc with 7 inputs and 7 outputs 

# ON-set COSt is c=34(34) in=128 out=34 tot=162 

# OFF-set cost is c=27 (27) in=75 Out=32 tOt = 107 

# DC-set cost is c=0(0) in=0 out=0 tot=0 

# Input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF-SET are disjoint 
DC- SET and OFF -SET are disjoint 

Union of ON-SET, OFF- SET and DC- SET is the universe 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -Dmapdc uuprblmrll . espdc 
> uuprblmrll . espphl ess 

sed -e '/Input phase is not/d' uuprblmrll , espphless > uuprblmrll . esp 
ttplanet uses 1st of these 

rm - f uuprblmrll . esp . tmpl uuprblmrll . esp . tmp2 uuprblmrll . esp . tmp3 
uuprblmrll . esp . comments uuprblmrll . espdc uuprblmrll . espphless 
/n/auspex6 / slO/chip/euterpe/ tools/bin/ espresso .mu < uuprblmrll . esp -eeat 
-Dcheck -v irred 


"grep PLANET_OPTS : 
-maxFanin 17 


Creating Verilog output file 


## Input phase is not 

PLA has 10 inputs 4 outputs 

Phase 1111 
Making net list. . . 
WARNING: Input 


Writing Verilog file 


Maximum primary input 
Maximum input plane fanin: 7 
This pterm drives a 
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max-f anin=4 
max-f anin=4 
max-fanin=4 


# PLA is (stdin) with 6 inputs and 7 outputs 

# ON-set cost is c=15(15) in=44 out=15 tot=59 

# OFF-set cost is c=20(20) in=51 out=24 tot=75 

# DC-set cost is c=ll(ll) in=35 out=19 tot=54 

# Input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF-SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 
OPTS="grep DOESPRESSO_OPTS : < uuprblmrll . esp | \ 

sed -e ' s! A #/ . *DOESPRESSO_OPTS : !! ' -e 's!\*/!! r ; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $OPTS 
uuprblmrll . esp 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -Dso_both. . . 
Running /n/ auspex6/ si O/chip/euterpe/ tools /bin/ espresso . mu on output of 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -Dso_both. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu -Dopo. . . 
Reg: tot=31 cube=ll max-AND -fanin=4 raax-OR- f anin=3 max-f anin=4 

Sob: tot=27 cube=ll max-AND- f anin=4 max-OR- f anin=3 

SobReg: tot=27 cube=10 max-AND- fan in= 4 max-OR- fanin= 3 
Opo: tot=25 cube=9 max-AND- fanin= 4 max-OR-fanin=3 

=> Espresso -Dopo provides the best solution. 
Output in uuprblmrll .do esp. out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits < uuprblmrll . doesp . out > 
uuprblmrll . opt esp . tmp 

rm -f uuprblmrll .doesp . out uuprblmrll. doesp. opo \ 

uuprblmrll . doesp . sob uuprblmrll . doesp . reg uuprblmrll . doesp . sobreg 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat "grep PLAT_OPTS : < 
uuprblmrll . esp | \ 

sed -e 1 s ! *#/ . *PLAT_OPTS: ! ! ' -e ' sl\*/!I' " uuprblmrll.optesp.tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat : opening Espresso- format input 
file "uuprblmrll.optesp.tmp' for reading 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : parsing PLA file and building 
datastructures . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : PLA has 6 inputs 7 outputs 9 
pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : Phase 1001011 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat : creating Planet input in 
"uuprblmrll . optesp. planet ' . . . 

mv uuprblmrll . opt esp. planet uuprblmrll . opt esp 
rm -f uuprblmrll.optesp.tmp 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet 
uuprblmrll .optesp | \ 

sed -e 's! A ##/.*PLANET_OPTS: ! ! ' -e 'sl\*/!! 
uuprblmrll . optesp 

/n/auspex6/sl0/chip/ euterpe/tools/bin/planet : 
input file "uuprblmrll . optesp ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Verilog output file 
"uuprblmrll . v 1 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Pirn output file 
"uuprblmrll .pirn ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Parsing PLA file and 
building datastructures... 

# /n/auspexS/slO/chip/euterpe/tools/bin/planet Version 0.1.28 Tue Feb 28 
14:41:06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/ tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
specified. 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : 
pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Phase 1001011 
/n/auspex6/s!0/chip/euterpe/tools/bin/planet : Making netlist... 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Verilog fd 
"uuprblmrll .v' . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Pirn file 
"uuprblmrll. pirn' . . . 


"grep PLANET_OPTS : < 
1 " -maxFanin 17 
Opening Espresso- format 


## Input phase is not 

PLA has 6 inputs 7 outputs 9 
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/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum primary input 
fanout: 3 [vldRll] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanin: 4 
[pterm 7] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : This pterm drives a 
maximum output plane fanin of: 3 [vldXcFrzLvaR12] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanout: 

2 [pterm 4] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum output plane fanin: 

3 [vldXcFrzLvaR12] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 4 pirn rows produced 
OCTTOOLS=/n/auspex6/slO/chip/euterpe/tools/vendor/octtools 
/n/auspex6/sl0/chip/euterpe/tools/vendor/octtools/bin/misll -x -c 
"read_eqn uuprblmrlO . esp . tmp2 ,- write_pla uuprblmrl0.esp.tmp3" 
"uuprblmrl0.esp.tmp2", line 177: node I prblmCdRll_4 * does not fanout 
sed -e 's!// !#//!' -e ' s ! A* !#/\* 1 1 < uuprblmrlO . esp . comments > 
uuprblmrlO . espdc 

cat uuprblmrlO . esp . tmp3 >> uuprblmrlO . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -eeat -Dcheck -v irred 
uuprblmrlO . espdc 

# PLA is uuprblmrlO . espdc with 8 inputs and 4 outputs 

# ON-set cost is c=42(42) in=205 out=42 tot=247 

# OFF-set COSt is C=37(37) in=149 out=58 tOt=207 

# DC-set cost is c=0(0) in=0 out=0 tot=0 

# Input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF -SET are disjoint 
DC -SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC -SET is the universe 

/n/ auspex6/ si 0 /chip/ euterpe/ tools/bin/ espresso. mu -Dmapdc uuprblmrlO . espdc 
> uuprblmrlO .espphless 

sed -e '/mput phase is not/d' uuprblmrlO . espphless > uuprblmrlO . esp 
#planet uses 1st of these 

rm -f uuprblmrlO .esp. tmpl uuprblmrlO . esp . tmp2 uuprblmrlO . esp . tmp 3 
uuprblmrlO . esp . comments uuprblmrlO . espdc uuprblmrlO . espphless 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu < uuprblmrlO . esp -eeat 
-Dcheck -v irred 

# PLA is (stdin) with 7 inputs and 4 outputs 

# ON-set cost is c=26(26) in=137 out=26 tot=163 

# OFF-set cost is c=22(22) in=94 out=38 tot=132 

# DC-set cost is c=ll(ll) in=40 out=31 tot=71 

# Input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 
OPTS="grep DOESPRESSO_OPTS : < uuprblmrlO . esp | \ 

sed -e ' s I A #/ . * DOES PRE SSO_OPTS : I ! ' -e 'sl\*/ll ,fc ; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $OPTS 
uuprblmrlO . esp 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu . . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu -Dso_both. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu on output of 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -Dso_both. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu -Dopo . . . 
Reg: tot=3 2 cube =9 max- AND- f anin=4 max- OR- f anin=4 max-fanin=4 

Sob: tot=37 cube=9 max- AMD- f anin=4 max- OR- f anin=3 max-fanin=4 

SobReg: tot=37 cube=9 max- AND- f anin=4 max- OR- f anin=3 max- f anin=4 
Opo: tot=37 cube=9 max - AND - f anin= 4 max- OR- f anin=3 max- f anin=4 

==> Espresso provides the best solution. 
Output in uuprblmrl 0 . doesp . out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits < uuprblmrlO . doesp . out > 
uuprblmrlO . opt esp . tmp 

rm - f uuprblmrlO . doesp . out uuprblmrlO . doesp . opo \ 

uuprblmrlO . doesp . sob uuprblmrlO . doesp . reg uuprblmrlO . doesp . sobreg 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat "grep PLAT_OPTS: < 
uuprblmrlO . esp | \ 

sed -e 1 s ! A #/ . *PLAT_OPTS: ! I ' -e 's!\*/!!' " uuprblmrlO . optesp . tmp 
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/n/auspex6/sl0/chip/euterpe/tools/bin/plat : opening Espresso- format input 
file "uuprblmrlO . optesp . tmp ' for reading 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : parsing PLA file and building 
data structures . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : PLA has 7 inputs 4 outputs 9 
pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : creating Planet input in 
"uuprblmrlO .opt esp. plane t ' . . . 

mv uuprblmrlO . opt esp . planet uuprblmrlO . optesp 
rm - f uuprblmrlO . optesp . tmp 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet "grep PLANETOPTS : < 
uuprblmrlO . optesp | \ 

sed -e 1 s! *##/ .* PLANE T_OPTS : ! ! ' -e T s!\*/M' " -niaxFanin 17 
uuprblmrlO . optesp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Opening Espresso- format 
input file "uuprblmrlO . optesp ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Verilog output file 
"uuprblmrlO . v 1 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Pim output file 
"uuprblmrlO .pirn 1 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Parsing PLA file and 
building datastructures . . . 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet Version 0.1.28 Tue Feb 28 
14:41:06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : ## Input phase is not 
specified. 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : PLA has 7 inputs 4 outputs 9 
pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Phase 1111 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Making netlist... 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Verilog file 
"uuprblmrlO .v ' . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Pim file 
"uuprblmrlO .pim 1 . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum primary input 
fanout: 7 [isRsrvdRlO] 

/n/auspex6/ slO/chip/euterpe/ tools/bin/planet : Maximum input plane fanin: 4 
[pterm 6] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : This pterm drives a 
maximum output plane fanin of: 4 [prblmCdMlRll<l>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanout: 
2 [pterm 6] 

/n/auspex6 /slO/ chip/ euterpe/ tools /bin/planet : Maximum output plane fanin: 
4 EprblmCdMlRll<l>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 2 pim rows produced 
OCTTOOLS= /n/auspex6/ si 0/chip/euterpe/ tools/ vendor /oct tools 
/n/auspex6/sl0/chip/euterpe/tools/vendor/octtools/bin/misll -x -c 
" read_eqn uuprblrarl3 . esp . tmp2 ; write_jpla uuprblmrl3 . esp . tmp3 11 
M uuprblmrl3 . esp. tmp2 " , line 155: node 1 rupt __0 1 does not fanout 
sed -e ' s !//!#//!' -e 1 s ! /\* ! #/\* ! ' < uuprblmrl 3 . esp. comments > 
uuprblmrl3 . espdc 

cat uuprblmrl 3 . esp . tmp3 >> uuprblmrl3 . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -eeat -Dcheck -v irred 
uuprblmrl3 . espdc 

# PLA is uuprblmrl3 . espdc with 11 inputs and 5 outputs 

# ON-set cost is c=106(106) in=687 out=106 tot=793 

# OFF-set cost is c=70(70) in=327 out=113 tot=440 

# DC-set cost is c=0(0) in=0 out=0 tot=0 

# Input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 

/n/auspex6/ slO/chip/euterpe/ tools/bin/espresso .mu -Dmapdc uuprblmrl3 .espdc 
> uuprblmrl3 .espphless 

sed -e '/Input phase is not/d 1 uup rblmr 13 . espphless > uuprblmrl3 . esp 
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#planet uses 1st of these 

rm - f uuprblmrl3 . esp . trapl uuprblmrl3 . esp . tmp2 uuprblmrl3 . esp . tmp3 
uuprblmrl3 . esp . comments uuprblmrl3 . espdc uuprblmrl3 . espphless 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu < uuprblmrl3 . esp -eeat 
-Dcheck -v irred 

# PLA is (stdin) with 10 inputs and 5 outputs 

# ON-set cost is c=76(76) in=537 out=76 tot=613 

# OFF-set cost is c=61(60) in=312 out=90 tot=402 

# DC-set cost is c=8(8) in=32 out=35 tot=67 

# Input phase is not specified. 
ON- SET and DC-SET are disjoint 
ON-SET and OFF- SET are disjoint 
DC-SET and OFF-SET are disjoint 

Union of ON- SET , OFF-SET and DC- SET is the universe 
OPTS="grep DOES PRE SSO_OPTS : < uuprblmrl3 . esp | \ 

sed -e »s! A #/.*DOESPRESSO_OPTS: ! ! ' -e 's!\*/!! l ~; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $OPTS 
uuprblmrl3 . esp 

Running /n/auspex6/s!0/chip/euterpe/tools /bin/espresso. mu. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -Dso_both. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu on output of 
/n/auspex6/sl0/chip/euterpe/ tools/bin/espresso. mu -Dso_both. . , 
Running /n/auspex6/sl0 /chip/euterpe/tools/bin/espresso .mu -Dopo. . . 
Reg: tot=105 cube- 19 max- AND- f anin=5 max-OR- fanin=7 max-fanin=7 

Sob: tot-13 2 cube=2S max- AND- f anin=5 max-OR- fanin=7 max-fanin=7 

SobReg: tot=108 cube=2 0 max- AND- f anin=5 max-OR- fanin=7 max-fanin=7 
Opo: tot=88 cube=16 max-AND- f anin=5 max-OR- fanin=8 max-fanin=8 

=> Espresso -Dopo provides the best solution. 
Output in uuprblmrl3 . doesp.out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits < uuprblmrl 3 .doesp.out > 
uuprblmrl3 . opt esp . tmp 

rm - f uuprblmrl 3 . doesp . out uuprblmrl 3 . doesp . opo \ 

uuprblmrl 3 . doesp . sob uuprblmrl3 . doesp . reg uuprblmrl3 . doesp . sobreg 
/n/auspex6/sl0/chip/euterpe/ tools/bin/plat "grep PLAT_0PTS: < 
uuprblmrl 3 .esp | \ 

sed -e 1 s ! *#/ . *PLAT_OPTS : i i ' -e 'slX*/!! 1 * uuprblmrl 3 . optesp . tmp 
/n/auspex6 /slO/chip/euterpe/ tools/bin/plat : opening Espresso- format input 
file "uuprb lmr 13 .optesp . tmp ' for reading 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : parsing PLA file and building 
datastructures . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : PLA has 10 inputs 5 outputs 16 
pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : Phase 01111 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat: creating Planet input in 
"uuprblmrl 3 . opt esp. planet 1 . . . 

mv uuprblmrl 3 . optesp . planet uuprblmrl 3 . optesp 
rm - f uuprblmrl 3 . optesp . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet ""grep PLANET_OPTS : < 
uuprblmrl3 .optesp | \ 

sed -e 's!"##/.*PLANET_OPTS: ! ! ' -e 's»\*/!!' ~ -maxFanin 17 
uuprblmrl 3 . optesp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Opening Espresso- format 
input file ""uuprblmrl 3 . optesp 1 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Verilog output file 
"uuprblmrl 3 . v ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Pirn output file 
"uuprblmrl3 .pirn' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Parsing PLA file and 
building datastructures. . . 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet Version 0.1.28 Tue Feb 28 
14:41:06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : ## Input phase is not 
specified. 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : PLA has 10 inputs 5 outputs 
16 pterins 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Phase 01111 
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/n/auspex6 /si O/chip/euterpe/ tools/bin/planet: Making netlist. . . 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Verilog file 
"uuprblmrl3 . v* . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Pirn file 
"uuprblmr 13 .pirn' . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum primary input 
fanout: 12 [vldNoooR13] 

/n/auspex6 /si O/chip/euterpe/ tools/bin/planet : Maximum input plane fanin: 5 
[pterm 6] 

/n/auspex6 /slO/chip/euterpe/ tools/bin/planet : This pterm drives a 
maximum output plane fanin of: 6 [vldPrblmCdR14<3>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanout: 
4 [pterm 93 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum output plane fanin: 
8 [vldPrblmCdR14<4>] 

/n/auspex6 /si O/chip/euterpe/ tools/bin/planet : 5 pirn rows produced 
OCTTOOLS=/n/auspex6/slO/chip/euterpe/ tools/vendor /octtools 
/n/auspex6 /si O/chip/euterpe/ tools/vendor /octtools/bin/misll -x -c 
" read_eqn uuprblmr8 . esp . trap 2 ; wr ite_pla uuprblmr 8 . esp . tmp3 ■ 
" uuprblmr 8 . esp. tmp2" , line 216: node 'prblmCdR9_4 * does not fanout 
sed -e 's !//[#//!' -e ' s ! A* ! #/\* ! 1 < uuprblmrS . esp . comments > 
uuprblmr 8 . espdc 

cat uuprblmr 8 . esp . tmp3 >> uuprblmr 8 . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -eeat -Dcheck -v irred 
uuprblmr8 . espdc 

# PLA is uuprblmr8 . espdc with 3 3 inputs and 9 outputs 

# ON-set cost is c=94(94) in=5 01 out=94 tot=595 

# OFF-set cost is c=57(57) in=168 out=68 tot=236 

# DC-set cost is c=0(0) in=0 out=0 tot=0 

# Input phase is not specified. 
ON- SET and DC -SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF -SET and DC- SET is the universe 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -Dmapdc uuprblmrS .espdc 
> uuprblmr 8 . espphless 

sed -e '/Input phase is not/d' uuprblmr 8 . espphless > uuprblmrS . esp 
#planet uses 1st of these 

rm - f uuprblmr 8 . esp . tmpl uuprblmr 8 . esp . tmp2 uuprblmrS . esp . tmp3 
uuprblmr 8 . esp . comments uuprblmrS . espdc uuprblmrS . espphless 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu < uuprblmr8 . esp -eeat 
-Dcheck -v irred 

# PLA is (stdin) with 32 inputs and 9 outputs 

# ON-set cost is c=82(82) in=461 out=81 tot=542 

# OFF-set cost is c=51(51) in=158 out=61 tot=219 

# DC-set cost is c=3(3) in=7 out=12 tot=l9 

# Input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC-SET and OFF-SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 
OPTS="grep DOESPRESSO_OPTS : < uuprblmr8 .esp | \ 

sed -e 's!"#/ . *DOESPRESSO_OPTS; ! i » -e • s! W ! I ■ * ; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $OPTS 
uuprblmr 8 . esp 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu. . . 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -Dso_both. . . 

Running /n/auspex6/s!0/chip/euterpe/ tools/bin/espresso. mu on output of 

/n/auspex6/sl0/chip/euterpe/ tools /bin/espresso .mu -Dso_both. . . 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu -Dopo. . . 

Reg: tot=192 cube=41 max- AND- f anin=6 max-OR-f anin=14 max-fanin=14 

Sob: tot=14 8 cube=36 max- AND- f anin=6 max-OR- f anin=ll max-fanin=ll 

SobReg: tot=139 cube=33 max- AND -fan in= 6 max-OR- fanin= 11 max-fanin=ll 

Opo: tot=13 9 cube=3 3 max- AND- f anin=6 max-OR- fanin* 11 max-fanin=ll 

=> Espresso -Dso_both | Espresso provides the best solution. 
Output in uuprblmr 8 . doesp . out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits < uuprblmr8 . doesp . out > 
uuprblmr 8 . opt esp . tmp 
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rm -f uuprblmrS . doesp.out uuprblmrS . doesp. opo \ 

uuprblmrS . doesp . sob uuprblrarS .doesp. reg uuprblmrS . doesp. sobreg 
OCTTOOLS»/n/auspex6/slO/chip/euterpe/tools/vendor/octtools 
/n/auspex6/sl0/chip/euterpe/tools/vendor/octtools/bin/misll -x -c 
" read_eqn uuprblmrl2 . esp . tmp2 ; write_pla uuprblmrl2 . esp . tmp3 " 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat "grep PLAT_OPTS : < 
uuprblrar8 . esp | \ 

se d -e 's!*!/.* PLAT OPTS : ! ! 1 -e 's!\*/!!' * uuprblmr8 . optesp. trap 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : opening Espresso- format input 
file " uuprblmr 8 . optesp . tmp ' for reading 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : parsing PLA file and building 
datastructures . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat: PLA has 32 inputs 9 outputs 33 
pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : Phase 111000101 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat: creating Planet input in 
"uuprblmr8 . optesp . planet ' . . . 

mv uuprblmrS .optesp. planet uuprblmrS .optesp 
rm - f uuprblmr 8 . optesp . tmp 

/n/auspexS/slO/chip/euterpe/tools/bin/planet "grep PLANET_OPTS : < 
uuprblmrS . optesp | \ 

sed -e ' s! *##/ . *PLANET_OPTS : ! ! ' -e ' s!\*/M' ** -maxFanin 17 
uuprblmr8 . optesp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Opening Espresso- format 
input file "uuprblmrS . optesp ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Verilog output file 
"uuprblmr 8 . v » 

sed -e 1 s! //!#//!' -e ' s ! /\* ! #/\* J 1 < uuprblmr 12 . esp . comments > 
uuprblmr 12 . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Pim output file 
"uuprblmr 8 .pim 1 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Parsing PLA file and 
building datastructures. . . 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet Version 0.1.28 Tue Feb 28 
14:41:06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

cat uuprblmr 12. esp. tmp 3 >> uup rblmr 12 . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -eeat -Dcheck -v irred 
uuprblmrl2 . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : ## Input phase is not 
specified. 

# PLA is uuprblmrl2. espdc with 13 inputs and 5 outputs 

# ON-set cost is c=122(122) in=701 out=122 tot=823 

# OFF-set cost is c=82(81) in=458 OUt=122 tot=580 

# DC-set cost is c=0(0) in=0 out=0 tot=0 

# Input phase is not specified. 
ON -SET and DC- SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 

/n/auspex6/sl0/chip/euterpe/ tools/bin/espresso .mu -Dmapdc uuprblmrl2 .espdc 
> uuprblmrl2 . espphless 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : PLA has 32 inputs 9 outputs 
33 pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Phase 111000101 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Making netlist... 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Verilog file 
"uuprblmrB . v ' . . . 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : Writing Pim file 
"uup rblmr 8 .pim ' . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum primary input 
fanout: 6 [augAccTypR8<l>] 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : Maximum input plane fanin: 6 
[pterm 3] 

/n/ auspex6/sl0 /chip/ euterpe/ tools/bin/planet : This pterm drives a 
maximum output plane fanin of: 6 [repelFailR93 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanout: 


Exhibit C12 


Page 192 of 643 


3 [pterm 33] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum output plane fanin: 
11 [vaDisR9] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 16 pirn rows produced 
sed -e '/Input phase is not/d' uuprblmrl2 . espphless > uuprblmrl2 . esp 
#planet uses 1st of these 

rm -f uuprblmrl2 . esp . tmpl uuprblmrl2 . esp . tmp2 uuprblmrl2 . esp . tmp3 
uuprblmrl2 . esp . comments uuprblmrl2 . espdc uuprblmrl2 . espphless 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu < uuprblmrl2 . esp -eeat 
-Dcheck -v irred 

# PLA is (stdin) with 12 inputs and 5 outputs 

# ON-set cost is c=100(100) in=608 out=100 tot=708 

# OFF-set cost is c=72 (72) in=420 out=100 tot=520 

# DC-set cost is c=5{5) in=15 out=19 tot=34 

# Input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF-SET and DC-SET is the universe 
OPTS="grep DOESPRESSO_OPTS : < uuprblmrl2 . esp | \ 

sed -e 1 s ! A #/. * DOES PRE S SO_OPTS : ! ! ' -e »s!\*/il'"; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $OPTS 
uuprblmrl2 . esp 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu . . . 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu -Dso_both. . . 

OCTTOOLS=/n/auspex6/slO/chip/euterpe/tools/vendor/octtools 

/n/auspex6/sl0/chip/euterpe/tools/vendor/octtools/bin/misll -x -c 

"read_eqn uuprblmr9 . esp . tmp2 ; write_pla uuprblmr9 . esp. tmp3 " 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu on output of 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -Dso_both. . . 

sed -e 1 s I // ! #// ! 1 -e ' s I A* i #/\* ! ' < uup rblmr 9 . esp . comments > 

uuprblmr9 . espdc 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu -Dopo. . . 
cat uuprblmr9 . esp . tmp3 >> uuprblmr9 . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -eeat -Dcheck -v irred 
uuprblmr9 . espdc 

# PLA is uup rblmr 9 . espdc with 19 inputs and 8 outputs 

# ON-set cost is c=92{92) in=475 out=91 tot=566 

# OFF-set cost is c=54(54) in=217 out=93 tot=310 

# DC-set cost is c=0(0) in=0 out=0 tot=0 

# input phase is not specified. 
ON- SET and DC- SET are disjoint 
ON- SET and OFF -SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -Dmapdc uuprblmr9 . espdc 
> uuprblmr 9 . espphless 

sed -e '/Input phase is not/d' uuprblmr9 . espphless > uup rblmr 9 . esp 
#planet uses 1st of these 

rm - f uuprblmr 9 . esp . tmpl uuprblmr 9 . esp . tmp2 uuprblmr 9 . esp . tmp3 
uuprblmr 9 . esp . comments uuprblmr 9 . espdc uuprblmr 9 . espphless 
Reg: tot=98 cube=19 max-AND- f anin=7 max-OR-f anin= 9 max-fanin=9 

Sob: tot=102 cube=22 max-AND- f an in= 7 max-OR-f anin= 6 max-fanin=7 

SobReg: tot=98 cube=19 max- AND- fan in= 7 max-OR-f anin=6 max-fanin=7 
Opo: tot=107 cube=2 0 max-AND- f an in= 6 max-OR-f anin= 9 max-fanin=9 

=> Espresso provides the best solution. 
Output in uuprblmr 12 .doe sp . out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits < uup rblmr 12 . doesp . out > 
uup rblmr 12 . opt esp . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu < uuprblmr9 . esp -eeat 
-Dcheck -v irred 

rm -f uuprblmr 12 .doesp. out uuprblmrl2 . doesp . opo \ 

uuprblmrl2 . doesp . sob uuprblmr 12 . doesp . reg uuprblmr 12 . doesp . sobreg 

# PLA is (stdin) with 18 inputs and 8 outputs 

# ON-set cost is c=58 (58) in=355 out=56 tot=411 

# OFF-set cost is c=34(34) in=135 out=54 tot=189 

# DC-set cost is c=17(17) in=64 out=81 tOt=145 

# Input phase is not specified. 
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ON- SET and DC- SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC-SET is the universe 
OPTS=-grep DOESPRESSOOPTS : < uuprblmr9 . esp | \ 

sed -e 'sl A #/.*DOESPRESSO_OPTS: ! ! ' -e ' s J \ * / I i 1 ^ ; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $OPTS 
uuprblmr9 . esp 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat "grep PLAT_OPTS : < 
uuprblmr 12 . esp | \ 

sed -e ' s! A #/. *PLAT_OPTS; ! ! 1 -e 's!\*/!!» " uuprblmrl2 . optesp . tmp 
/n/auspex6/sl0 /chip/euterpe/ tools/bin/plat : opening Espresso- format input 
file * uuprblmr 12 . optesp . tmp 1 for reading 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : parsing PLA file and building 
datastructures . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : PLA has 12 inputs 5 outputs 19 
pterins 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : creating Planet input in 
~uuprblmrl2 . optesp .planet ' . . . 

mv uuprblmrl2 . optesp .planet uuprblmrl2 . optesp 

Running /n/auspex6/sl0 /chip/euterpe/ tools /bin/espresso .mu . . . 

rm - f uuprblmrl2 . optesp . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet "grep PLANET_OPTS : < 
uuprblmrl2 . optesp j \ 

sed -e 's! A ##/. * PLANETJDPTS : I I ' -e 'siX*/!!' " -maxFanin 17 
uuprblmrl2 . optesp 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -Dso^both. .. 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Opening Espresso- format 
input file * uuprblmr 12 . optesp f 

/n/auspex6/sl0/chip/euterpe/ tools/bin/planet : Creating Verilog output file 
"uuprblmrl2 . v ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Pirn output file 
"uuprblmrl2 . pirn ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Parsing PLA file and 
building datastructures... 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet Version 0.1.28 Tue Feb 28 
14:41:06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Input phase is not 
specified. 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : PLA has 12 inputs 5 outputs 
19 pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Phase 11111 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Making netlist... 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Verilog file 
"uuprblmrl2 . v 1 . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Pirn file 
"uuprblmrl2 .pirn 1 , . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum primary input 
fanout: 12 [gtlbCnf lctR12] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanin: 7 
[pterm 6] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : This pterm drives a 
maximum output plane fanin of: 3 [prblmCdR13<0>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanout: 
3 [pterm 10] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum output plane fanin: 
9 [prblmCdR13<3>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 6 pirn rows produced 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso . mu on output of 
/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -Dso_both. . . 
Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso .mu -Dopo. . . 
Reg: tot=112 cube=23 max- AND- f anin=9 max-OR- f anin=ll max-fanin=ll 

Sob: tot=131 cube=2 6 max- AND- f anin=10 max-OR- fanin= 7 max-fanin=10 

SobReg: tot =121 cube=23 max - AND -f anin=10 max-OR- fanin= 7 max-fanin=10 
Opo: tot=104 cube=18 max-AND-f anin=10 max-OR- fanin= 7 max-fanin=10 

=> Espresso -Dopo provides the best solution. 
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Output in uuprblmr 9 . doesp . out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits < uuprblmr9 .doesp. out > 
uuprblmr9 . optesp . tmp 

rm -f uuprblmr9 .doesp . out uuprblmr9 . doesp. opo \ 

uuprblmr9.doesp. sob uuprblmr9 . doesp . reg uuprblmr9 . doesp . sobreg 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat "grep PLAT_OPTS : < 
uuprblmr9 . esp | \ 

sed -e ' s I *#/ . *PLAT_OPTS : ! ! 1 -e 's!\*/!!' v uuprblrar 9 . optesp . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat : opening Espresso- format input 
file * uuprblmr 9 .optesp. tmp 1 for reading 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : parsing PLA file and building 
datastructures . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : PLA has 18 inputs 8 outputs 18 
pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : Phase 11001101 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat : creating Planet input in 
"uuprblmr9 . optesp. planet 1 . . . 

mv uuprblmr 9 . optesp .planet uuprblmr 9 . optesp 
rm - f uuprblmr 9 . optesp . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet "grep PLANET_OPTS : < 
uuprblmr9 . optesp j \ 

sed -e ' s! ^##/ . *PLANET_OPTS: ! ! ' -e ' s!\*/M' * -maxFanin 17 
uuprblmr9 . optesp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Opening Espresso- format 
input file * uuprblmr 9 . optesp ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Verilog output file 
"uuprblmr 9 . v' 

OCTTOOLS=/n/auspex6/slO/chip/euterpe/tools/vendor/octtools 
/n/auspex6/ si 0/chip/euterpe /tools /vendor /oct tools /bin/misll -x -c 
"read_eqn uuprblmwm.esp. tmp2 ; write_pla uuprblmwm. esp. tmp3 " 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Pirn output file 
"uuprblmr 9 .pirn 1 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Parsing PLA file and 
building datastructures... 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet Version 0.1.28 Tue Feb 28 
14:41:06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : ## Input phase is not 
specified. 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : PLA has 18 inputs 8 outputs 
18 pterms 

/n/auspex6 /slO/chip/euterpe/ tools/bin/planet : Phase 11001101 
/n/auspex6 /slO/chip/euterpe/ tools/bin/planet : Making netlist... 
/n/auspex6 /slO/chip/euterpe/ tools/bin/planet : Writing Verilog file 
"uuprblmr 9 . v ' . . . 

/n/auspex6/ slO/chip/euterpe/ tools/bin/planet : Writing Pirn file 
"uuprblmr 9 .pirn' . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum primary input 
fanout: 13 [prblmCdMlR9<l>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanin: 
10 [pterm 12] 

/n/auspex6/ slO/chip/euterpe/ tools/bin/planet : This pterm drives a 
maximum output plane fanin of: 2 [uuYieldsNblnRlO] 

/n/auspex6 /slO /chip/ euterpe/ tools /bin/planet : Maximum input plane fanout: 
3 [pterm 14] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum output plane fanin: 
7 [prblmCdMlR10<l>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 8 pirn rows produced 
sed -e ' si //!#//!' -e » s ! /\* I#/\* ! ' < uuprblmwm .esp . comments > 
uuprblmwm . espdc 

cat uuprblmwm.esp, tmp 3 >> uuprblmwm . espdc 

/n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu -eeat -Dcheck -v irred 
uuprblmwm . espdc 

# PLA is uuprblmwm. espdc with 18 inputs and 10 outputs 

# ON-set cost is c=178(178) in=1039 out=178 tot=1217 

# OFF-set cost is c=64{64) in=233 OUt=154 tot=387 

# DC-set cost is c=0(0) in=0 out=0 tot=0 
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# Input phase is not specified. 
ON- SET and DC-SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 

/n/auspex6/ si O/chip/euterpe /tools/bin/espresso . mu -Dmapdc uuprblmwm . espdc 
> uuprblmwm. espphless 

sed -e '/Input phase is not/d' uuprblmwm. espphless > uuprblmwm . esp 
#planet uses 1st of these 

rm -f uuprblmwm . esp . tmpl uuprblmwm . esp . tmp2 uuprblmwm. esp. tmp3 
uuprblmwm . esp . comments uuprblmwm . espdc uuprblmwm . espphless 
/n/ auspexS/ si O/chip/euterpe /tools /bin/ espresso .mu < uuprblmwm. esp -eeat 
-Dcheck -v irred 

# PLA is (stdin) with 17 inputs and 10 outputs 

# ON-set cost is c=138(138) in=855 out=138 tot=993 

# OFF-set cost is C=48(48) in=180 out=100 tot=280 

# DC-set cost is c=17{17) in=67 out=74 tot=141 

# Input phase is not specified. 
ON- SET and DC-SET are disjoint 
ON- SET and OFF- SET are disjoint 
DC- SET and OFF- SET are disjoint 

Union of ON- SET, OFF- SET and DC- SET is the universe 
OPTS="grep DOESPRESSO_0PTS : < uuprblmwm . esp | \ 

sed -e T s ! *#/ . *DOESPRESSO_OPTS : 1 ! 1 -e • s ! W M 1 " ; \ 
/n/auspex6/sl0/chip/euterpe/tools/bin/doespresso -fanin 17 $OPTS 
uuprblmwm . esp 

Running /n/auspex6/sl O/chip/euterpe/ tools/bin/espresso . mu. . . 

Running /n/auspex6/sl O/chip/euterpe/ tools/bin/espresso. mu -Dso both. . . 

Running /n/auspex6/sl0/chip/euterpe/tools/bin/espresso.mu on output of 

/n/auspexe/slO/chip/euterpe/tools/bin/espresso.mu -Dso_both. . . 

Running /n/auspex6/sl0 /chip/euterpe/ tools/bin/espresso .mu -Dopo. . . 

Reg: tot=161 cube=32 max- AND- f anin=ll max-OR-f anin=10 max-fanin=ll 

Sob: tot=180 cube- 3 5 max- AND- f anin=ll max-OR- f anin=7 max-fanin=ll 

SobReg: tot=14 2 cube=28 max-AND- f anin=ll max-OR-f anin=7 max-fanin=ll 

Opo: tot=120 cube=21 max- AND- fanin- 11 max-OR-f anin=8 max-f anin=ll 

=> Espresso -Dopo provides the best solution. 
Output in uuprblmwm. doe sp. out 

/n/auspex6/sl0/chip/euterpe/tools/bin/consbits < uuprblmwm. doe sp. out > 
uuprblmwm . optesp . tmp 

rm - f uuprblmwm . doesp . out uuprblmwm . doesp . opo \ 

uuprblmwm . doesp . sob uuprblmwm . doesp . r eg uuprblmwm. doesp. sobr eg 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat "grep PLAT_OPTS: < 
uuprblmwm. esp j \ 

sed -e ' s ! A #/ . *PLAT_OPTS : M ' -e 1 s!\*/!!' " uuprblmwm. optesp . tmp 
/n/auspex6/sl0/chip/euterpe/tools/bin/plat : opening Espresso- format input 
file "uuprblmwm . optesp . tmp 1 for reading 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : parsing PLA file and building 
datastructures . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : PLA has 17 inputs 10 outputs 
21 pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/plat : Phase 0001110111 
/n/auspex6/sl0/chip/e\iterpe/tools/bin/plat : creating Planet input in 
* uuprblmwm. opt esp. planet ' . . . 

mv uuprblmwm. optesp. planet uuprblmwm. optesp 
rm - f uuprblmwm . optesp . tmp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet "grep PLANE T_OPTS : < 
uuprblmwm . optesp | \ 

sed -e ' s !*##/.* PLANET_OPTS : !! 1 -e 's!\*/!!' " -maxFanin 17 
uuprblmwm . optesp 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Opening Espresso- format 
input file "uuprblmwm . optesp ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Verilog output file 
"uuprblmwm. v ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Creating Pim output file 
" uuprblmwm . pim ' 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Parsing PLA file and 
building datastructures. . . 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet Version 0.1.28 Tue Feb 28 
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14 : 41: 06 PST 1995 

# /n/auspex6/sl0/chip/euterpe/tools/bin/planet -clock -diffin -diffout 
-flipflop -rank 1 -verilog 

/n/auspex6 /si 0 /chip/euterpe/ tools /bin/planet : ## Input phase is not 
specified. 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : PLA has 17 inputs 10 outputs 
21 pterms 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Phase 0001110111 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Making netlist... 
/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Verilog file 
"uuprblmwm. V . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Writing Pirn file 
"uuprblmwm.pim' . . . 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum primary input 
fanout: 11 [vldPrblmCdWM<l>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanin: 
11 [pterm 21] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : This pterm drives a 
maximum output plane fanin of: 2 [vldXcptnUnlckWN] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum input plane fanout: 
4 [pterm 13] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : Maximum output plane fanin: 
8 [vldPrblmCdWN<0>] 

/n/auspex6/sl0/chip/euterpe/tools/bin/planet : 6 pirn rows produced 
echo uu.v uucmp2rn.v uuovrlyregreg. v uuxlutrap.v uuprblmfrz.v uuprblmup.v 
uupreemuq.v uuthruut.v uurbuu.v uuholduu.v uursltbypauu . v uursltbypbuu . v 
uursltbypcuu . v uujoblstux.v uuchkdstuw.v uuchkdstr3.v uuprblmrO.v 
uuprblmrS.v uuprblmr7.v uuprblmr8.v uuprblmr9.v uuprblmrlO.v uuprblmrll.v 
uuprblmrl2 . v uurupt rl2 . v uuprblmr 13 . v uuprblmwm . v uubruw . v uuwewj . v 
uuissrcur.v uuthruus.v uuimmus.v uudstselut.v uuimmpcut.v uumicut.v 
uum i cuu . v uui sds tuv . v uubyp 1 tncyuv . v uubruv , v uumemuv . v uur s rvd . v 
uurstuq.v uusteput.v uustepuu.v uuovrlyregregcyl . v uuovrlysrcdstbyp . v 
uuovrlysrcdst2xe . v uuovrlysrcdstcyl . v uucmp2rncx.v | tr ' ' '\012' > 
vf iles 

gmake [1]: Leaving directory * /N/auspex6/sl0/chip/euterpe/verilog/bsrc/uu ' 
gmake[l]: Entering directory 

VN/auspex6/slO/chip/euterpe/verilog/bsrc/xlu' 
gmake [1] : "vfiles' is up to date. 

gmake [1] : Leaving directory * /N/auspex6/sl0/chip/euterpe/verilog/bsrc/xlu 1 
rm -f vfiles 

for i in at au cc cdio ce eg cj ck cp ctioi ctiod dr drio es gf gt he hz 
ice ife io iq It mst mc nb rg rgxmit sr uu xlu; do \ 

sed -e '/ A $/d' < ${i}/vfiles | sed -e »s! A !${i}/!" » vfiles; \ 

done 

[finished at Sat Mar 11 01:44:21 PST 1995 exit status 0] 
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From: lisar (Lisa Robinson) 

Sent: Saturday, March 11, 1995 4:51 AM 

To: 'doi'; 'lisar'; 'tbr'; 'torn'; 'chip' 

Cc: 'euterpe-checkins-dist' 

Subject: Release of BOMs by lisar (euterpe) 

Checkin Message: 

Releasing these to be picked up in the next toplevel releasbom 

BOM Update in euterpe BOM 3.463 
BOM Update in euterpe/verilog BOM 3.367 
BOM Update in euterpe/verilog/bsrc BOM 250. 1 
Releasing Files: 

i_euterpe_wrap.tb, i_euterpe_wrap.vhdl 
BOM Release in euterpe/verilog/bsrc BOM 250.1 
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From: lisar (Lisa Robinson) 

Sent: Saturday, March 11 , 1 995 4:54 AM 

To: 'hopper'; 'sysadm' 

Subject: vlit down 

I will restart it. 
Lisa R. 

lisar@rhodan /s3/euterpe/verilog/bsrc 425 % vlit 

=== interHDL vlit version 2.5 ==== 
(c) Copyright 1992-1994, interHDL inc 

Checking out license... 

Feature 04: License server is down. 
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From: lisar (Lisa Robinson) 

Sent: Saturday, March 11, 1995 5:54 AM 

To: 'sysadm' 

Subject: vlit 


Well I had just been typing vlit to find out if the license 
server was up ... and it kept saying it was down. This used to 
work for me. 

However my make completed just fine .. this is what it used 
rNTERHDL_ELMHOST=rhea 

INTERHDL_KEY_DIR=/ii/rhodan/s3/eute^ 'cat 
ikos_list' -sce!l_list -v -r0.05 -e -s vlit_cell_list 
Checking out license... 
Done. 

Lisa R. 
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From: 


tbr 


Sent: 
To: 

Cc: 


Subject: 


Saturday, March 11, 1995 10:40 AM 
'solo (John Campbell)' 
'geert (Geert Rosseel)'; 'torn (Tom Laidig)' 
Re: snapshot 


Follow Up Flag: Follow up 
Flag Status: Red 

John Campbell wrote (on Sat Mar 1 1): 
as Tim B. Robinson was saying 

..I started a make in the snapshot to pick up the changes fred had made 
..to fix csyn errors from ea cells. For some reason, it decided to 
..recompile leafgen! 

..Any ideas why? 


We changed several makefiles, i don't think leafgen should have been 
affected but my senior assistant, tau may have an opinion. 

It was, and now the timing is re-running. Take a look at the log in 
s23/euterpe-proteus-cp/makerrs 


..Tim 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, March 11, 1995 10:41 AM 

'solo (John Campbell)' 

'geert (Geert Rosseel)'; 'torn (Tom Laidig)' 

Re: snapshot 


John Campbell wrote (on Sat Mar 11) : 

as Tim B. Robinson was saying 

. . I started a make in the snapshot to pick up the changes f red had made 
..to fix csyn errors from ea cells. For some reason, it decided to 
..recompile leaf gen! 

. .Any ideas why? 


We changed several makefiles. i don't think leaf gen should have been 
affected but my senior assistant, tau may have an opinion. 

It was, and now the timing is re- running. Take a look at the log in s2 3 /euterpe-proteus- 


Tim 


cp/makerrs 


Tim 
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From: geert (Geert Rosseel) 
Sent: Saturday, March 1 1 , 1 995 2: 1 0 PM 
To: 'dickson'; 'hopper'; 'tbr'; 'wampler' 
Subject: GARDS problem ... URGENT 


Hi, 

I am trying to build at in the snapshot and it gets stuck at the 
first gplace (at-passl). When I do a gardslic, it is there, but 
what I do a "top" on gamorra, I see : 

13201 geert 1 0170508K OK sleep 3:17 0.00% 0.00% <gplace> 

I tried it earlier this morning on staypuft and I got the same result. 
I need this at before I can build a top-level. I think I'll need help to 
resolve this 

The data is in the snapshot /n/auspex/s41/euterpe-snapshot/euterpe/verilog/bsrc/at 
The makefile output is in bsrc/at/gards/makerrs 
Geert 
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From: wampler (Kurt Wampler) 

Sent: Saturday, March 11, 1995 2:34 PM 

To: 'dickson'; 'geert'; 'hopper'; 'tor' 

Subject: Re: GARDS problem ... URGENT 


Geert writes : 


>I am trying to build at in the snapshot and it gets stuck at the first 
>gplace (at-passl) . When I do a gardslic, it is there, but what I do a 
>"top" on gamorra, I see : 

> 

> 13201 geert 1 0170508K OK sleep 3:17 0.00% 0.00% <gplace> 

> 

>I tried it earlier this morning on staypuft and I got the same result. 
>I need this at before I can build a top-level. I think I'll need help 
>to resolve this 
> 

>The data is in the snapshot 

/n/auspex/ s41/euterpe- snapshot /euterpe/verilog/bsrc /at 
> 

>The makefile output is in bsrc/at/gards/makerrs 

I think clio is having a problem that is causing your GPLACE job to hang. 
I can't get fully logged in to clio to test things out, but your GPLACE 
job is trying to put its window on clio and I think clio's catatonic 
state is the source of the hangup . 

As a workaround, why don't you kill the currently executing gmake & gplace 
and override the display pointer to point to thoas : 

gmake GARDS_DISPLAY= thoas : 0 [other parameters] 

If clio needs to be rebooted, I could get over to M.U. later this 
afternoon and give it the boot . 

- Kurt 
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From: lisar (Lisa Robinson) 

Sent: Saturday, March 1 1 , 1 995 8:26 PM 

To: 'mws'; 'billz'; 'dickson'; 'woody'; 'tbr'; 'jeffm' 

Subject: Test status 


BOM 247 running on Zycad 
BOM 250 running on IKOS 


New business 

regdepend_r25547 238 - miscompare on gmshril 6 (should take an exception but doesn't) 
tried to recreate with same operands but ran ok - aphrodite /s3 24295.8960 
244 - This test Ran OK on IKOS am running again on Zycad 


stgen_r 1 33 1 1_0 240 - Miscompare trace on nosferatu /s4/res/3395 . 1 3 608 
250 - Dump on staypuft /s3/tbr/euterpe/verilog/bsrc 
I think that there are at least 3 failures in this test 
I only looked at cyl 0. 1 have marked the levellog with 
<-- comments. 


doublemctest_0 250 - Bad rhodan /s3 1 1 395.4206 

icachenoalloc_0 250 - 249 dump on staypuft /s3/tbr/euterpe/verilog/bsrc 

dramprintharder2 250 - X dump on nosferatu /s5/euterpe/verilog/bsrc 

atomic_conflict_l 250 - rhodan /s3 1 1395.6066 

Thread 3, Reg 0, Param Entry 2 Expected 1020304050607 Got baadbeefbaadbeef 

xlu_field_4_l 250 - X (Ran for much longer) rhodan /s3 1 1 395.5887 

dcache_perf_stlt_l 250 - Cache Data Error Expected 200000000000, Got 200000000000 Expected 200000000080, Got 
200000000080 

Expected 200000000108, Got 200000000108 Expected 2000000001d8, Got 2000000001d8 

Expected 200000000ff8, Got 200000000ff8 
dcache_perf_ldst5t_l 250 - Exxxexpppcpeeetecccectttdteee edddd 
200020220200000000000000000004000010000000004000041,4401 1 1000 ,G„, o 
You get the picture! Traces for both on rhodan /s3 1 1395.2390 

cache_U 249 - X traces on rhodan /s3 likedriverlog 5395. 1 338 vlduv_debug 1 0395.25580 

sync_l 249 - hung rhodan /s3 10395.25253 cache_debug 

icache_stress 249 - X /s3 rhodan 10395.8826 (and 6395.2961) and 10395.24485 snake_debug 

nbjiermesj 247 - nosferatu /s2 10395.501 7 

hermesload_0 247 - hermes model problem 

Old Business - Need to reun and if necessary redump these 

hermesjatetumon 24 1 - trace on nosferatu /s2 1 9295 .285 1 0 

Recreated with icachenoalloc 

icache_func_l 244 - trace on rhodan /s3 5395.2288 (hung) 
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Recreated with dramprintharder2 

dcache_sz_l 6k_l 24 1 - Printed test name then X - rhodan /s3 2395.6392 
mem_U 244 - Printed P then went to X rhodan /s3 4395 . 1 5296 

interrupt_U } 
gtlb_miss_U } 

barreLU } 244 - All X - rhodan /s3 5395.1338 

bgateJJ } 

dcache_except 244 - dcache tag exception 2 was not recieved when expected 
exception bit set in tag but not in GTLB - rhodan /s3 6395.296 1 
trying to re-create with dcacheharder5 

unix_l 250 - Re-running now 

cerberrtest 247 - X trace on nosferatu /s2 8395. 1 6920 

cerbarbeasy O Lisa R to run again as verilog run is well behaved 

Performance Failures (Test ran to completion but failed performance measure) 


dcache_perf_ldlt_l Expected difference between the cached and non-cached access = 4600-5050 cycles 

Actually took 3650 fewer cycles rhodan /s3 24295.8260 
icache_perf_lt_l Expected difference between the cached and non-cached access = 46000-50600 cycles 

Actually took 1 23 800 fewer cycles rhodan /s3 26295 .14314 
icache_perf_5t_l Expected difference between the cached and non-cached access = 58000-63800 cycles 

Actually took 1 17120 (!) fewer cycles rhodan /s3 6395.3461 
nb_l Actual accept time = 160:1 86 Expected accept time = 150:1 80 rhodan /s3 28295.4379 

nb_slow Actual accept time = 160:186 Expected accept time - 150: 1 80 rhodan /s3 28295.4379 

Have not yet been run: 

hermes load J) 

nb_combo_l 

addr_map_rom - new but doen't compile 

hermes_conflict_l 
dcachecon fl ict_ 1 

ruptpintest 0 - Need to build a "custom" simulator 

inter leave_l 

interleaveJU 
exceptionU 
tlbJJ 
synchU 

Cannot yet be run: 

instrJU 

instr_l 

tlb_l 

insn_l 

nulltest 

XLU tests 

xlu_rotate_l_l 
xlu_rotate_2_l 
xlu_expand_l_l 
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xlu_compress_l_l 

xlu_extract_l_l 

xlu_field_l_l 

xlu_field_2_l 

xlu_field_3_l 

xlu_copy swap_ 1_ 1 

xlu_copy swap_2_ 1 

xlu_copy swap_3 1 

xlu_copy swap_4_ 1 

xlu_shufflemux_l_l 

xlu_select_l_l 

Not yet implemented: 


brcolltest_0 

brcrosstestj) 

brimmlongtest 0 

expriotest_0 

canceltest_0 

hermtotestj) 

cerbtotest_0 

hermerrtestO 

eventregtest_0 

exintbashtestO 

cerberror_0 

testerinitO 

memmap__0 

nbbashtest_0 

cerbarbtests 

hcplltests 

addr_mad_void 
addr_map_mc 
addr_map_cerb 
addr_map_hermes 

node-boot 
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From: lisar (Lisa Robinson) 

Sent: Saturday, March 11, 1995 9:40 PM 

To: 'jeffm' 

Cc: 'billz'; 'dickson'; 'guarino'; 'mws'; 'tbr'; 'woody' 
Subject: instr_1.de 

Jeff 

The tests instr and insn are not currently built by the default target. 
1 tried to build instr and got 

lisar@nosferatu /s2/euterpe/stb/stand/diag 445 % gmake HWSIM=1 CHIPROOT=/n/nosferatu/s2/euterpe instr_l.cie 
/n/nosferatu/s2/euterpe/tools/vendor/soft/stb/bin/tgcc -DDEBUG LE VEL_ 1 -DNO_CALLIOPE -DSHORT - 
MDupdate .depend -L./lib -g-02 -c instr main, c -o instr main 1 .o 

/n/nosferatu/s2/euterpe/tools/vendor/soft/stb/bin/tgcc -xassembler-with-cpp -DDEBUGLEVELl -DNO_CALLIOPE 

DSHORT -MDupdate .depend -I.Vlib -g -02 -c address.s -o address_l.o 

address. s: Assembler messages: 

address. s:94: Error: Unknown opcode: 'aaddi' 

address.s: 97: Error: Unknown opcode: 'aaddi' 

address.s: 109: Error: Unknown opcode: 'aadd' 

address.s: 1 10: Error: Unknown opcode: 'aadd' 

address.s: 121: Error: Unknown opcode: 'aand' 

address.s: 122: Error: Unknown opcode: 'aand' 

address.s: 1 3 1 : Error: Unknown opcode: 'aandn' 

address.s: 132: Error: Unknown opcode: 'aandn' 

address.s: 141: Error: Unknown opcode: 'anand' 

address.s: 142: Error: Unknown opcode: 'anand' 

address.s: 1 51 : Error: Unknown opcode: 'anor' 

address.s: 152: Error: Unknown opcode: "anor* 

etc 

I suspect that this is why it was put in the cannot run yet category. 
Lisa R. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Sunday, March 12, 1995 1:54 AM 
'Kurt Warn pier' 

'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)'; 'torn (Tom Laidig)'; 'wampler (Kurt Wampler)' 
Re: Routing experiment 


Kurt Wampler writes: 

I've completed a [perhaps interesting] routing experiment. Predicated on 
the idea that early wafers will be non-airbridge and nitride dielectric all 
the way to the top (i.e. M2 capacitance parasitic will be roughly the same as 
M3/M4), I ran a routing strategy that had full freedom in the M2 layer 

- - no 

length limit. I used Geert 1 s placement from Friday. 

Disconnects after line search: 822 ( 1:39:25) CPU time (medusa) 
Disconnects after maze: 159 ( 5:29:42) " 

Disconnects after ripper: 40 (15:16:06) « 

Results are in /n/godzilla/s2/wampler/euroute/geert_euterpe-iter . df f . 

The ripper solved almost everything except the right corridor. It churned 
wires up there for many hours, ripping and rerouting, but just seemed to 
not have enough vertical resource to succeed. It might be possible to get 
those last 40 nets by hand, but it would probably take several hours. 


didn't PGROUTE this design, so even if I did manually figure out a way to 
finish up the last 40 unroutes, it wouldn't be something we could export & 
LVS. 

However .. .going back to the original assumption, it might be interesting to 
take wire lengths with estimated nitride non- airbridge capacitance 
coefficients 

out of this route and into simulation and see just what speed the chip would 
run at in this condition. I don't know how much work that would be on the 
simulation side, but it wouldn't take long to produce the capacitance numbers 
if the coefficients were known. 


I think this _is_ an interestng result. In fact, based on this result, and, as you 
mention, the possibility of the first chips from the fab using a nitride dielectric, I 
would say we are presented with (at least) 2 new 

choices: 1. Work on refining your route further to get rid of all disconnects and then see 
what the resulting speed is. 2. Explicitly turn down the clock to reduce cell size and 
congestion and then attempt a re-route. This second approach may, possibly, give us a 
faster chip than 1. if it results in fewer serpentine wires. I would say that both these 
experiments are worth pursuing further. 


I 


Kurt, 


Comments? 


- thanks , 
hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 
Sunday, March 12, 1995 9:23 AM 
'geert' 

'hopper'; 'tbr*; 'torn'; 'wampler' 
Routing experiment 


Hi, 


I've completed a [perhaps interesting] routing experiment. Predicated on the idea that 
early wafers will be non-airbridge and nitride dielectric all the way to the top (i.e. M2 
capacitance parasitic will be roughly the same as M3/M4) , I ran a routing strategy that 
had full freedom in the M2 layer no length limit. I used Geert 1 s placement from 
Friday. 

Disconnects after line search: 822 ( 1:39:25) CPU time (medusa) 
Disconnects after maze: 159 (5:29:42) " 

Disconnects after ripper: 40 (15:16:06) " 

Results are in /n/godzilla/s2/wampler/euroute/geert_euterpe- iter . df f . 

The ripper solved almost everything except the right corridor. It churned wires up there 
for many hours, ripping and rerouting, but just seemed to not have enough vertical 
resource to succeed. It might be possible to get those last 40 nets by hand, but it would 
probably take several hours. I didn't PGROUTE this design, so even if I did manually 
figure out a way to finish up the last 40 unroutes, it wouldn't be something we could 
export & LVS . 

However ... going back to the original assumption, it might be interesting to take wire 
lengths with estimated nitride non-airbridge capacitance coefficients out of this route 
and into simulation and see just what speed the chip would run at in this condition. I 
don't know how much work that would be on the simulation side, but it wouldn't take long 
to produce the capacitance numbers if the coefficients were known. 


- Kurt 
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From: 


tbr 


Sent: 


Subject: 


To: 


Sunday, March 12, 1995 12:59 PM 
'brianl' 

Spoke too soon 


Follow Up Flag: Follow up 
Flag Status: Red 


Making mltime/mlmuxen7dfl6s.tim 
deal: end hera stdout 

deal: begin hera stderr (child 2683 1, cmd 259, exit 0) ... 
deal: end hera stderr (child 2683 1) 

deal: child 29285 dealing command 276 to merope % echo Making mltime/mlmuxen8dfts.tim; cd ./mltime; 

CHIPROOT=/n/auspex6/s23/euterpe-proteus-cp CHIP=proteus ../tools/simulate-time mlmuxen8df8s 

deal: child 29304 dealing command 277 to hera % echo Making mltime/mlmuxen8dhl2s.tim; cd ./mltime; 

CHIPROOT=/n/auspex6/s23/euterpe-proteus-cp CHIP=proteus ../tools/simulate-time mlmuxen8dhl2s 

deal: child 29388 dealing command 278 to phobos % echo Making mltime/mlmuxen8dhl6s.tim; cd ./mltime; 

CHIPROOT=/n/auspex6/s23/euterpe-proteus-cp CHIP=proteus ../tools/simulate-time mlmuxen8dh!6s 

Deal parent cleaning up ... Done 

Deal child 29304 caught signal 2. 

Deal child 29285 caught signal 2. 

Deal child 29304 killing process group 29305 

Deal child 29285 killing process group 29286 

Deal child 28937 caught signal 2. 

Deal child 28918 caught signal 2. 

Deal child 28937 killing process group 28942 

Deal child 28918 killing process group 28919 

Deal child 28841 caught signal 2. 

Deal child 20099 caught signal 2. 

Deal child 28841 killing process group 28842 

Deal child 20099 killing process group 20100 

Deal child 28860 caught signal 2. 

Deal child 28860 killing process group 28861 

Deal child 29223 caught signal 2. 

Deal child 29223 killing process group 29224 

Deal child 29388 caught signal 2. 

Deal child 29388 killing process group 29389 

deal: begin hera stdout (child 29304, cmd 277) ... 

deal: end hera stdout 

deal: begin hera stderr (child 29304, cmd 277, terminated 2) ... 
deal: begin psyche stdout (child 28918, cmd 273) ... 
deal: end psyche stdout 

deal: begin psyche stderr (child 28918, cmd 273, terminated 2) ... 
deal: begin polyhymnia stdout (child 28937, cmd 274) ... 
deal: end polyhymnia stdout 

deal: begin polyhymnia stderr (child 28937, cmd 274, terminated 2) ... 
deal: begin phobos stdout (child 29388, cmd 278) ... 
deal: end phobos stdout 

deal: begin phobos stderr (child 29388, cmd 278, terminated 2) ... 
deal: begin mercury stdout (child 29223, cmd 275) ... 
deal: end mercury stdout 

deal: begin mercury stderr (child 29223, cmd 275, terminated 2) ... 
deal: begin ares stdout (child 28841, cmd 271) ... 
deal: end ares stdout 

deal: begin ares stderr (child 28841, cmd 271, terminated 2) ... 
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deal: begin merope stdout (child 29285, cmd 276) ... 
deal: end merope stdout 

deal: begin merope stderr (child 29285, cmd 276, terminated 2) ... 

deal: end psyche stderr (child 28918) 

deal: begin pelorus stdout (child 20099, cmd 210) ... 

deal: end pelorus stdout 

deal: begin pelorus stderr (child 20099, cmd 210, terminated 2) ... 
deal: begin kephalos stdout (child 28860, cmd 272) ... 
deal: end kephalos stdout 

deal: begin kephalos stderr (child 28860, cmd 272, terminated 2) ... 

deal: end hera stderr (child 29304) 

deal: end ares stderr (child 2884 1 ) 

deal: end polyhymnia stderr (child 28937) 

deal: end phobos stderr (child 29388) 

deal: end merope stderr (child 29285) 

deal: end pelorus stderr (child 20099) 

deal: end mercury stderr (child 29223) 

deal: end kephalos stderr (child 28860) 

gmake[2]: *** [do-mlobe-time] Error 1 

gmake[2]: Leaving directory */N/auspex6/s23/euterpe-proteus-cp/leafgen' 
gmake[l]:*** [all] Error 1 

gmake[l]: Leaving directory */N/auspex6/s23/euterpe-proteus-cp/leafgen' 
gmake: *** [proteusmake] Error 1 
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From: brianl (Brian Lee) 

Sent: Sunday, March 12, 1995 1:01 PM 

To: Tim B. Robinson' 

Subject: Re: Spoke too soon 

Oops. Sorry. This is my fault. I accidently killed the snapshot trying 
to terminate my leafgen release. Please restart yours and it should 
continue cleanly. 

Brian 

Tim B. Robinson writes: 


jMaking mltime/mlmuxen7dfl6s.tim 
Ideal: end hera stdout 

jdeal: begin hera stderr (child 26831, cmd 259, exit 0) ... 
Ideal: end hera stderr (child 2683 1) 

jdeal: child 29285 dealing command 276 to merope % echo Making mltime/mlmuxen8df8s.tim; cd ./mltime; 

CHIPROOT=/n/auspex6/s23/euterpe-proteus-cp CHIP=proteus ../tools/simulate-time mlmuxen8df8s 

(deal: child 29304 dealing command 277 to hera % echo Making mltime/mlmuxen8dhl2s.tim; cd ./mltime; 

CHIPROOT=/n/auspex6/s23/euterpe-proteus-cp CHIP^proteus ../tools/simulate-time mlmuxen8dhl2s 

]deal; child 29388 dealing command 278 to phobos % echo Making mltime/mlmuxen8dhl6s.tim; cd ./mltime; 

CHIPROOT=/n/auspex6/s23/euterpe-proteus-cp CHIP=proteus ../tools/simulate-time mlmuxen8dhl6s 

JDeal parent cleaning up ... Done 

|Deal child 29304 caught signal 2. 

|Deal child 29285 caught signal 2. 

|Deal child 29304 killing process group 29305 

|Deal child 29285 killing process group 29286 

|Deal child 28937 caught signal 2. 

|Deal child 28918 caught signal 2. 

|Deal child 28937 killing process group 28942 

|Deal child 28918 killing process group 28919 

|Deal child 28841 caught signal 2. 

|Deal child 20099 caught signal 2. 

(Deal child 28841 killing process group 28842 

jDeal child 20099 killing process group 20100 

|Deal child 28860 caught signal 2. 

(Deal child 28860 killing process group 28861 

|Deal child 29223 caught signal 2. 

(Deal child 29223 killing process group 29224 

jDeal child 29388 caught signal 2. 

jDeal child 29388 killing process group 29389 

jdeal: begin hera stdout (child 29304, cmd 277) ... 

jdeal: end hera stdout 

jdeal: begin hera stderr (child 29304, cmd 277, terminated 2) ... 
jdeal: begin psyche stdout (child 2891 8, cmd 273) ... 
|deal: end psyche stdout 

jdeal: begin psyche stderr (child 28918, cmd 273, terminated 2) ... 
jdeal: begin polyhymnia stdout (child 28937, cmd 274) ... 
jdeal: end polyhymnia stdout 

jdeal: begin polyhymnia stderr (child 28937, cmd 274, terminated 2) ... 
jdeal: begin phobos stdout (child 29388, cmd 278) ... 
jdeal: end phobos stdout 

jdeal: begin phobos stderr (child 29388, cmd 278, terminated 2) ... 
jdeal: begin mercury stdout (child 29223, cmd 275) ... 
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Ideal: end mercury stdout 

jdeal: begin mercury stderr (child 29223, cmd 275, terminated 2) ... 
Ideal: begin ares stdout (child 28841, cmd 271) ... 
Ideal: end ares stdout 

jdeal: begin ares stderr (child 28841, cmd 271, terminated 2) ... 
jdeal: begin merope stdout (child 29285, cmd 276) ... 
jdeal: end merope stdout 

jdeal: begin merope stderr (child 29285, cmd 276, terminated 2) ... 

jdeal: end psyche stderr (child 28918) 

jdeal: begin pelorus stdout (child 20099, cmd 210) ... 

jdeal: end pelorus stdout 

jdeal: begin pelorus stderr (child 20099, cmd 210, terminated 2) ... 
jdeal: begin kephalos stdout (child 28860, cmd 272) ... 
jdeal: end kephalos stdout 

jdeal: begin kephalos stderr (child 28860, cmd 272, terminated 2) ... 

jdeal: end hera stderr (child 29304) 

Ideal: end ares stderr (child 28841) 

(deal: end polyhymnia stderr (child 28937) 

jdeal: end phobos stderr (child 29388) 

jdeal: end merope stderr (child 29285) 

jdeal: end pelorus stderr (child 20099) 

jdeal: end mercury stderr (child 29223) 

jdeal: end kephalos stderr (child 28860) 

jgmake[2]: *** [do-m lobe-time] Error 1 

jgmake[2]: Leaving directory */N/auspex6/s23/euterpe-proteus-cp/leafgen' 
|gmake[l]: *** [all] Error 1 

jgmake[l]: Leaving directory > /N/auspex6/s23/euterpe-proteus-cp/leafgen' 
jgmake: *** [proteusmake] Error 1 

I 


Brian L. 
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From: hopper (Mark Hofmann) 

Sent: Sunday, March 12, 1995 1:33 PM 

To: 'geert (Geert Rosseel)' 

Subject: Top-Level Euterpe route: How's it going? 


I noticed you've been working on the top-level route through the weekend. 
How are things looking currently? 

-mark 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Sunday, March 12, 1995 1:56 PM 
'woody (Jay Tomlinson)' 
'woody' 
status 


Follow Up Flag: Follow up 
Flag Status: Red 


Jay Tomlinson wrote (on Tue Mar 7): 
To Do for main board compile: 

1 . Decide what to do about chips_prt. I vote for sticking with the gyg 
because we already know how to deal with it. 

We convinced rich staying with the gyg files was the best course, and 
dan has been implementing the chips_prt generator. 

2. Move all of the schematics to the new directory structure. If you 
attempt to browse the schematic, you will need to set up links to the 
hestia/ged dir (see my set up). 

Some additional issues have been raised by tbe and we should spend a 
few minutes thinking through what we really want. 

3 . Put together the necessary Makefiles similar to the euterpe module. 

Dan has been concentrating on the euterpe module and was still having 
problems as of friday. He said he would have it all completed over 
the weekend. 

4. Eventually all of the old stuff should be cvs rm'ed. 


Yes. 
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From: 
Sent: 
To: 


tbr 


Sunday, March 12, 1995 2:10 PM 
'Curtis Abbott' 

'billz@microunity.com'; 'lisar@microunity.com' 
Euterpe SDRAM 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Curtis Abbott wrote (on Thu Mar 9): 

What is the scenario where we might want this? 

A cable modem based on Euterpe might need other than onchip memory. 
Clearly, this could be slower than 100MHz, and it would be nice if it 
could be found in increments smaller than 4MB. Given the poor 
availability of 4Mb SDRAM, 2MB increments based on a single 16Mb chip 
would probably be a good solution. 

Another consideration is that the SDRAM controller design is based on 
the assumption that there is a fairly large multiplier between the 
SOFA clock rate SDRAM clock rate. So, although we have a great deal 
of programmability in the timing, resolution becomes poor at low 
SOFA clock rates and we may lose significant performance in the SDRAM 
as a result. 


Tim 
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From: 
Sent: 
To: 
Cc: 

Subject: 


torn (Tom Laidig (tau)) 

Sunday, March 12, 1995 9:40 PM 

Tim B. Robinson' 

'solo (John Campbell)'; 'geert (Geert Rosseel)'; 'tau'; 'brianl (Brian Lee)' 
Re: snapshot 


Tim B. Robinson writes: 

John Campbell wrote (on Sat Mar 11) : 
as Tim B . Robinson was saying . . . . 


made 


I started a make in the snapshot to pick up the changes fred had 


For some reason, it decided to 


to fix csyn errors from ea cells, 
recompile leaf gen! 

Any ideas why? 

Tim 


We changed several makefiles. i don't think leaf gen should have been 
affected but my senior assistant, tau may have an opinion. 

It was, and now the timing is re -running. Take a look at the log in 
s23/euterpe-proteus-cp/makerrs 

It looks to me as if proteus/ spice /misc / {oper_pt . h, header } were rebuilt because brianl 
just added a dependency of it on the spice models file. 
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From: tbr 

Sent: Sunday, March 12, 1995 11:49 PM 

To: 'torn (Tom Laidig (tail)' 

Cc: 'brianl (Brian Lee)'; 'geert (Geert Rosseel)'; 'solo (John Campbell)'; 'tau* 

Subject: Re: snapshot 
Follow Up Flag: Follow up 

Flag Status: Red 


tau wrote (on Sun Mar 12): 
Tim B. Robinson writes: 

I John Campbell wrote (on Sat Mar 11): 

I as Tim B. Robinson was saying 

j ..I started a make in the snapshot to pick up the changes fred had made 
j ..to fix csyn errors from ea cells. For some reason, it decided to 
j ..recompile leafgen! 

j ..Any ideas why? 

| ..Tim 

I We changed several makefiles, i don't think leafgen should have been 

j affected but my senior assistant, tau may have an opinion. 

jit was, and now the timing is re-running. Take a look at the log in 
js23/euterpe-proteus-cp/makerrs 

It looks to me as if proteus/spice/misc/{oper_pt,h, header} were rebuilt 
because brianl just added a dependency of it on the spice models file. 

Yes, it's grinding along, hopefully not destroying anything as it 
goes! 

Tim 


Exhibit C12 


Page 219 of 643 


Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, March 12, 1995 11:49 PM 

'torn (Tom Laidig (tail))' 

'brianl (Brian Lee)'; 'geert (Geert Rosseel)'; 'solo (John Campbell)'; 'tau' 
Re: snapshot 


tau wrote (on Sun Mar 12) : 


Tim B. Robinson writes: 


John Campbell wrote (on Sat Mar 11) : 


as Tim B . Robinson was saying 


I started a make in the snapshot to pick up the changes fred had 


made 


to fix csyn errors from ea cells. For some reason, it decided to 
recompile leaf gen ! 


Any ideas why? 


Tim 


We changed several makefiles. i don't think leaf gen should have 

been 

affected but my senior assistant, tau may have an opinion. 

It was, and now the timing is re- running. Take a look at the log in 
s23 /euterpe-proteus - cp/makerr s 

It looks to me as if proteus/spice/misc/ {oper_pt .h, header} were rebuilt 
because brianl just added a dependency of it on the spice models file. 

Yes, it's grinding along, hopefully not destroying anything as it goes! 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Monday, March 1 3, 1 995 1 :07 AM 

To: 'mws'; 'dickson'; Veena' 

Cc: 'doi'; 'jeffm'; 'Wife'; 'woody'; 'tbr' 

Subject: regdepend_r25547_0 

I spent some time trying to re-create the gmshril6 failure of 
regdepend_r25547_0, which if you recall failed on BOM 238 (not taking 
an exception when it should have) and running okay now. I did a getbom 
of 238 but getbom got me 238. 12 which went to x because it contained 
the "pruned gates". I did a bit of groping around in cvs logs and 
with the help of tbr realised that the problem may be that the gates 
just weren't in BOM 238. 

The results of the run were at: 

33720 -rw-r~r-- 1 lisar 34495400 Feb 24 1 1 :32 res/24295. 8960/resu!ts/regdepend_r25547_0.or 


Here are mws's comments at 4.30 pm that day: 
revision 239.0 

date: 1995/02/24 16:30:11 LT; author: woody; state: Exp; lines: +1 -1 
Release Target: euterpe/verilog/bsrc 

Added xlu trap conditions to uu that were removed from mc by dickson. 

Now we (as in tbr et al) think that this exception gmshri 16 was at 
that point only added to the standalone datapath simulation envirnment 
not in the top level. Which would explain why the test didn't take the 
exception and runs now. 

So, am I off the hook? Are we satisfied that the failure is 
understood? 

Lisa R. 
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From: lisar (Lisa Robinson) 

Sent: Monday, March 13, 1995 10:38 AM 

To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr'; 'woody' 

Cc: 'doi'; 'geert' 

Subject: Test status 


BOM 24 7 running on Zycad 
BOM 252 running on IKOS 

New business 


icachenoalloc_0 252 - Hung rhodan /s3 13395.19696 - will run in 

verilog. 

regdepend_r2 554 7 238 - miscompare on grashrilS (should take an 
exception but doesn't) 

Believe that these gates were not in 238 - aphrodite /s3 

24295 .8960 

244 - This test Ran OK on IKOS am running again on Zycad 

stgen_rl3 311_0 240 - Miscompare trace on nosferatu 

/s4/res/3395. 13608 

250 - Dump on staypuft 
/s3/tbr/euterpe/verilog/bsrc 

I think that there are at least 3 failures in this test 

I only looked at cyl 0. I have marked the levellog with 
<-- comments. 

doublemctest_0 250 - Bad rhodan /s3 11395.4206 

dramprint harder 2 250 - X dump on nosferatu /s5/euterpe/verilog/bsrc 

atomic_conf lict_l 250 - rhodan /s3 11395.6066 

Thread 3, Reg 0, Param Entry 2 Expected 
1020304050607 Got baadbeef baadbeef 

xlu_f ield_4_l 2 50 - X (Ran for much longer) rhodan /s3 

11395.5887 

dcache_perf_stlt_l 250 - Cache Data Error Expected 200000000000, Got 

200000000000 Expected 200000000080, Got 200000000080 

Expected 200000000108, Got 
200000000108 Expected 2000000001d8 , Got 2000000001d8 

Expected 200000000f f 8 , Got 

200000000f f 8 

dcache_perf_ldst5t_l 2 50 - Exxxexpppcpeeetecccectttdteee edddd 
200020220200000000000000000004000010000000004000041,440111000 ,G, , , o 

You get the picture] Traces for both on rhodan /s3 113 95.2390 

dcache_conf lict_l 250 Thread 3, Reg 1, Param Entry 2 Expected 
1020304050607 Got f f f f df f f f f f f f f f f - trace on rhodan /s3 11395.6701 

cache_U 249 - X traces on rhodan /s3 likedriverlog 

5395.1338 vlduv_debug 103 95.25580 

sync_l 24 9 - hung rhodan /s3 10395.25253 cache_debug 

icache_stress 249 - X /s3 rhodan 10395.8826 (and 63 95.2961) and 

10395.24485 snake_debug 

nb_hermes_l 247 - nosferatu /s2 10395.5017 

hermesload_0 24 7 - hermes model problem 

instr_l 251 - X } rhodan /s3 12395.11603 
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insn_l 251 - X } 

tlb_l 250 - X rhodan /s3 11395.6933 

regdepend_r25728_0 247 - 2 cyl hung? nosferatu /s2 11395.86062 

interleave_l 247 - X and doesn't enable hermes (comment in log 

says otherwise?) nosferatu /s2 11395.15228 

dcacheharder5_0 251 - I think that this failed - I need to look at 

this one. 

Old Business - Need to reun and if necessary redump these 
hermes_lateturnon 241 - trace on nosferatu /s2 19295.28510 
Recreated with icachenoalloc 

icache_func_l 244 - trace on rhodan /s3 5395.2288 (hung) 

251 - rhodan /s3 12395.13205 hung 

Recreated with dramprint harder 2 

dcache_sz_16k_l 241 - Printed test name then X - rhodan /s3 

2395.6392 

mem_U 244 - Printed P then went to X rhodan /s3 

4395 .15296 
interrupt_U 
gtlb_miss_U 

barrel_U } 244 - All X - rhodan /s3 5395.1338 

bgate_U } 


! 


dcache_except 244 - dcache tag exception 2 was not recieved when 

expected 

exception bit set in tag but not in GTLB - rhodan /s3 6395.2961 
trying to re-create with dcacheharderS 

unix^l 250 - Re -running now 

cerberrtest 247 - X trace on nosferatu /s2 83 95.16920 

cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 

Performance Failures (Test ran to completion but failed performance 
measure) 


dcache_perf_ldlt_l Expected difference between the cached and 

non-cached access = 4600-5050 cycles 

Actually took 3650 fewer cycles rhodan /s3 24295.8260 
icache_jperf_lt_l Expected difference between the cached and 
non-cached access - 46000-50600 cycles 

Actually took 123800 fewer cycles rhodan /s3 

26295.14314 

icache_perf_5t_l Expected difference between the cached and 
non-cached access = 58000-63800 cycles 

Actually took 117120 (1) fewer cycles rhodan /s3 

6395.3461 

nb_l Actual accept time = 160:186 Expected accept time 

= 150:180 rhodan /s3 28295.4379 

nb_slow Actual accept time = 160:186 Expected accept time 

= 150:180 rhodan /s3 28295.4379 

Have not yet been run: 

hermes_load_0 

nb_combo__l 

hermes conflict l 
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ruptpintest_0 - Need to build a "custom" simulator 

inter leave_l 

interleave_U 
exceptionJJ 
tlb_U 
synch_U 

Cannot yet be run: 


instr_U 

instr_l 

tlb_l 

insn_l 

nulltest 

XLU tests 


xlu_rotate_l_l 

xlu_rotate_2_l 

xlu_expand_l_l 

xlu_compress_l_l 

xlu_extract_l_l 

xlu_field_l_l 

xlu_f ield_2_l 

xlu_f ield_3_l 

xlu_copyswap_l_l 

xlu_c opy s wap_2 _1 

xlu_copyswap_3_l 

xl u_c opy s wap_4 _1 

xl u_s hu f f 1 emux_l_l 

xlu_select_l_l 

Not yet implemented: 


brcolltest_0 

brcrosstest_0 

brimmlongtest_0 

expriotest_0 

cancel test__0 

hermtotest_0 

cerbtotest_0 

hermerrtest_0 

event regtest_0 

exintbashtest_0 

cerberror_0 

testerinit_0 

memmap_0 

nbbashtest_0 

cerbarbtests 

hcplltests 

addr_mad_void 
addr_map_mc 
addr_map_c e rb 
addr_map_he rme s 

node -boot 
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From: woody (Jay Tomlinson) 
Sent: Monday, March 13, 1995 11:32 AM 
To: 'tbr (Tim B. Robinson)' 
Subject: status 

Tim B. Robinson wrote (on Sun Mar 12): 
Jay Tomlinson wrote (on Tue Mar 7): 
To Do for main board compile: 

1 . Decide what to do about chips_prt. I vote for sticking with the gyg 
because we already know how to deal with it. 

We convinced rich staying with the gyg files was the best course, and 
dan has been implementing the chips_prt generator. 

2. Move all of the schematics to the new directory structure. If you 
attempt to browse the schematic, you will need to set up links to the 
hestia/ged dir (see my set up). 

Some additional issues have been raised by tbe and we should spend a 
few minutes thinking through what we really want. 

3. Put together the necessary Makefiles similar to the euterpe module. 

Dan has been concentrating on the euterpe module and was still having 
problems as of friday. He said he would have it all completed over 
the weekend. 

4. Eventually all of the old stuff should be cvs rm'ed. 
Yes. 

I realized that some more changes for connectors in morpheus/verilog/slibsrc 
will need to be made. They will need to be converted from vector to scalar 
notation to match the schematic body. This is what needed to be done anyway 
since it allows gyg2v to create the verilog directly from the gyg. Note gyg2v 
doesn't currently support vectors. 

woody 1 
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From: brianl (Brian Lee) 

Sent: Monday, March 13, 1995 5:00 PM 

To: 'ericm (Eric Murray)' 

Cc: 'tbr (Tim B. Robinson)' 

Subject: connection timed out errors in snapshot build 

Hi, 

Tim said that you wanted to be advised of our "network/system" problems 
so that you could try to track things. 

The latest snapshot proteus build failed because two (out of 836) mlobe 
simulations failed when the connection timed-out while trying to 
find/execute the hspice binary. Both time outs occurred on pelorus. 

E.g.: 

Vmlor2dh2s.scr: /n/auspex6/s23/euterpe-proteus-cp/tools/vendor/hspice/standara7 
bin/hspice: Connection timed out 

Time of error: 

brianl@gamorra 273% ll leafgen/mltime/mlor2dh2s.err26627 Ieafgen/m!time/rnlor2df8s.err26508 
I -rw-r-r- 1 chip 208 Mar 13 01:07 Ieafgen/mltime/mlor2df8s.err26508 
1 -rw-r-r- 1 chip 113 Mar 13 01:09 leafgen/mltime/mlor2dh2s.err26627 

Brian L. 
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From: 
Sent: 
To: 

Subject: 


Mark Semmelmeyer [mws@godzilla] 
Monday, March 13, 1995 6:31 PM 
'euterpe@godzilla' 

IMMINENT/FINAL DECISION: IQ cut from 7 to 4 quadlets; br pred impact 


As explained, below, we have essentially made a final decision to reduce the instruction 
queue from 7 quadlets to 4 quadlets . 

Since the decision is already essentially final, no date for it to become final or 
effective is given. 


We have always had a predicted branch&target alignment effect on ifetch performance that 
could affect loop performance. This effect was poorly advertised but only applicable to 
less than 1 of 16 random cases until recently. Of course, compilers or other tools might 
make the cases less than random for somewhat worse results. 

The size of the instruction queue was decided back in the old days when the on chip ifetch 
rate was once every four cycles (one can look at it as ticks or major cycles for the same 
relative result) . 

7 quadlets of queuing was the minimum necesary to keep straight line code free of ifetch 
delays, and that size is what we still had until now. Predicted branches could mostly 
live with 7 and not see delays, but there were a few cases that would have required even 
more quadlets in the instruction queue to avoid delays. 
We never claimed that predicted branch performance was perfect. 

Recently it became clear that routing congestion near the iCache made it impossible to 
support so much instruction queueing. 

The old instruction queue is now overkill when evaluated against the same criteria that 
originally justified it because the ifetch rate is now double what it was. The size 
justified by those criteria is 4 quadlets. This results in a new predicted branch 
performance rule once the excess quadlets are removed: 

A correctly predicted branch that does not hold in issue will cause its 
target to suffer a 1 tick ifetch delay if the branch and target PC's have 
the same (quadlet) offset within their hexlets. If the branch holds in 
issue for any reason (e.g. eta restriction, pc behind) then this ifetch 
delay does not apply, and if the target instruction was not ready to issue 
anyway, then the ifetch delay will trade with the otherwise 1st cycle of 
issue delay for no net loss. 

Examples of correctly predicted branches subject to pred ifetch delay: 

from pc=0x200 to pc=0xl80 

from pc=0x408 to pc=0x228 
Examples of correctly predicted branches NOT subject to pred ifetch 


from pc=0x200 to pc=0xl84 
from pc=0x408 to pc=0x22C 
from pc=0x400 to pc=0x22C 
from pc=0x3OC to pc=0xl78 

from pc^any to a load/ store/branch instruction 

With the excess that we had before, the rule was the same except only applied when the 
branch and target were both the FIRST quadlet in their own aligned hexlets. I think if we 
only had the quarter rate ifetch as originally planned, the rule would have been similar 
to what we are ending up with now with half rate ifetch and a 4 quadlet instruction queue. 


delay: 
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From: lisar (Lisa Robinson) 

Sent: Tuesday, March 14, 1995 12:26 AM 

To: 'jeffm'; 'mws' 

Subject: ovfloaduse ran ok on 247 


Summary file is res/13 3 95 . 19258/summary 


Design Name : c_euterpe_wrap 
Run Date: 133 95 

Run ID: 19258 


Simulator: c_euterpe_wrap .mif .mm was built on Tue Mar 7 21:46:11 1995 

Using BOM : Version BOM,v 247.0 1995/03/07 18:45:05 LT mws 
Warning: Local BOM is out of date . . . 
Log Message: 

Run started on host: aphrodite at: Mon Mar 13 17:33:53 PST 1995 

ovf loaduse__0 Ran ok 
Run time = 2 585 seconds Performance = 16 cycles/second 
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From: 
Sent: 
To: 
Cc: 

Subject: 


hopper (Mark Hofmann) 
Tuesday, March 14, 1995 1:36 AM 
'Kurt Wampler" 

'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)' 
Re: Inverse route order 


Kurt Wampler writes: 
Good evening - 

I completed the inverse-order routing experiment. It reached 98.95% 
completion (2784 disconnects) . The results are in: 

/n/godzilla/s2/wampler/ invroute/geert_euterpe- iter . df f 

. . .if anyone wants to have a look at the disconnect pattern. I can make a 
small plot of it tomorrow. At first glance, it doesn't look much different 
from the plots we were examining this afternoon. 

Okay. So this is simialr to, or slightly better than, the ordering we had been trying up 
to line search? (ca. 2900 disconnects?) 

Does that say that ordering is not critical. Or do we need another point on the curve to 
be able to draw such an inference? 


-hopper 
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From: wampler (Kurt Wampler) 

Sent: Tuesday, March 14, 1995 1:57 AM 

To: 'geert' 

Cc: 'billz'; 'dickson'; 'hopper 1 ; 'mws'; 'tbr'; 'vo'; 'wampler'; 'woody' 

Subject: Inverse route order 

Good evening - 

I completed the inverse-order routing experiment. It reached 98.95% completion (2784 
disconnects) . The results are in: 

/n/godzi 11a/ s2 /wampler / invroute/geert_euterpe- iter . df f 

. . . if anyone wants to have a look at the disconnect pattern. I can make a small plot of 
it tomorrow. At first glance, it doesn't look much different from the plots we were 
examining this afternoon. 


- Kurt 


{BTW - when I went to log in this evening from home there was some kind of severe 
network/NFS disturbance going on; I couldn't log in to any machine for about 15 minutes, 
and then when I did log in, my home directory on the auspex was inaccessible. Did anyone 
else experience problems like this?} 


[Also, FYI, the routing strategy used was:] 


control: net list = short . net ; flag=-l; routorder=-l ; 

maze: mazebox=10; xmazelimit=100 ; ymazelimit=24 ; first=l; last=l; 
linesearch: searchdepth=6 ; first=l; best=99; pinpair=-3; Maxdog (1) =10000 ; 
linesearch: searchdepth=4 0 ; first=l; best=99; pinpair=-3; Maxdog ( 1) =10000 ; 

control: netlist=all . net ; flag=-l; routorder=- 1 ; 
linesearch: searchdepth=6 ; first=2; best=99; pinpair=-3; 
linesearch: searchdepth=4 0 ; first=2; best=99; pinpair=-3; 


+delay 0 L2 
+delay 15 L123 

+1 $CHIPROOT/tools/bin/galoadobs %.dff sof a_pads_spars . obs 
+garout -listing %■ . gar out . lis .phase 1 -protectpins 2 
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Cc: 

Subject: 


From: 
Sent: 
To: 


vanthof (vant) 

Tuesday, March 14, 1995 8:56 AM 

'tbr (Tim B. Robinson)'; 'vo (Tom Vo)'; 'geert (Geert Rosseel)'; 'lisar (Lisa Robinson)*; 'hopper 
(Mark Hofmann)' 
Vanthof (Dave Van't Hof)' 
mnemo drc's finished 


The mnemo upper drc ' s have finished and aside some notch errors in the metals from the 
router and via twinner, the metals are clean. 

The lowers are basically clean EXCEPT for 5 big holes in the poly layer: 

93560, 6000 
93720, 6000 
67680, 5520 
69840, 5520 
178560, 5520 

The floating poly check died when it filled up the disk. Is it possible to have larger 
than 2GB partitions on sunos? We've reached the point where a single stage within a 
dracula run for mnemo exceeds the current file system sizes created for dracula jobs. 
These are currently about 1.6GB and it would be nice to have about 3GB per partition. 

I'll manually fix and restart the floating poly check. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 


Thanks , 
Dave 
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Sent: 

To: 

Cc: 


Subject: 


From: 


hopper (Mark Hofmann) 
Tuesday, March 14, 1995 9:12 AM 
'vant' 

"tbr (Tim B. Robinson)'; Vo (Tom Vo)'; 'geert (Geert Rosseel)'; 'lisar (Lisa Robinson)'; 'vanthof 

(Dave Van't Hot)' 

Re: mnemo drc's finished 


vant writes: 

The mnemo upper drc's have finished and aside some notch errors in the 
metals from the router and via twinner, the metals are clean. 

Good news ! 

The lowers are basically clean EXCEPT for 5 big holes in the poly 
layer : 

93560, 6000 
93720, 6000 
67680, 5520 
69840, 5520 
178560, 5520 

Any idea what the source of these are? 

The floating poly check died when it filled up the disk. Is it possible to 
have larger than 2GB partitions on sunos? We've reached the point where 
a single stage within a dracula run for mnemo exceeds the current file 
system sizes created for dracula jobs. These are currently about 1.6GB and 
it would be nice to have about 3GB per partition. 

I thought this was now possible. 

I'll manually fix and restart the floating poly check. 

Thanks , Dave . 


Thanks , 
Dave 


-hopper 


Exhibit C12 


Page 232 of 6 


From: lisar (Lisa Robinson) 

Sent: Tuesday, March 14, 1995 10:30 AM 

To: 'billz'; 'dickson'; 'jeffm'; 'mws*; 'tbr'; 'woody' 

Cc: 'doi'; 'geeif 

Subject: test status 


BOM 24 7 running on Zycad 
BOM 253 running on IKOS 

New business 


Next group on rhodan /s3 13395.100: 
mem_U 253 - Ran ok 

bgate_U 253 - hung 

barrel_U 253 - no exception handler for cylinder 1 at pc 

0x9005f 03800001188 

interrupt_U Need to re -run 

gtlb_miss_U 253 - unexpect exception 15 at pc 0x200000000c57 : 

cache_U 252 - X traces on rhodan /s3 likedriverlog 

5395.1338 vldUV_debug 10395.25580 

prblm_debug 14 3 95.107 

sync_l 253 - X rhodan /s3 103 95.25253 cache_debug 

vldUV_debug 14 3 95.326 

icachenoalloc_0 252 - Hung rhodan /s3 13395.19696 sump on 

staypuft /s5/tbr/euterpe 

stgen_rl3311_0 240 - Miscompare trace on nosferatu 

/s4/res/3395. 13608 

250 - Dump on staypuft 
/s3/tbr/euterpe/verilog/bsrc 

I think that there are at least 3 failures in this test 

I only looked at cyl 0. I have marked the levellog with 
<-- comments. 

doublemctest_0 250 - Test fix is just need to re-run 

atomic_conf lict_l 250 - rhodan /s3 113 95.6066 

Thread 3 , Reg 0 , Param Entry 2 Expected 
1020304050607 Got baadbeef baadbeef 

xlu_f ield_4_l 2 50 - X (Ran for much longer) rhodan /s3 

11395.5887 

dca cheaper f_stlt_l 250 - Cache Data Error Expected 200000000000, Got 

200000000000 Expected 200000000080, Got 200000000080 

Expected 200000000108, Got 
200000000108 Expected 2000000001d8 , Got 2000000001d8 

Expected 200000000f f 8 , Got 

200000000ff 8 

dcache_perf_ldst5t_l 2 50 - Exxxexpppcpeeetecccectttdteee edddd 
200020220200000000000000000004000010000000004000041,440111000 ,G, , , O 

You get the picture! Traces for both on rhodan /s3 11395.2390 

dcache_conf lict_l 250 Thread 3, Reg 1, Param Entry 2 Expected 
1020304050607 Got f f f f df f f f f f f f f f f - trace on rhodan /s3 11395.6701 

icache_stress 249 - X /s3 rhodan 10395.8826 (and 6395.2961) and 

10395.24485 snake_debug 

nb_hermes_JL 247 - nosferatu /s2 10395.5017 

hermesload_0 247 - hermes model problem 
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instr_l 251 - X } rhodan /s3 12395.11603 

insn_l 2 51 - X j 

tlb_l 250 - X rhodan /s3 11395.6933 

regdepend_r2572 8_0 24 7 - 2 cyl hung? nosferatu /s2 113 95.86062 

interleave_l 247 - X and doesn't enable hermes (comment in log 

says otherwise?) nosferatu /s2 113 95.1522 8 

Old Business - Need to reun and if necessary redump these 
hermes_lateturnon 241 - trace on nosferatu /s2 192 95.28510 
Recreated with icachenoalloc 

icache_func_l 244 - trace on rhodan /s3 5395.2288 (hung) 

251 - rhodan /s3 12395.13205 hung 

dcache_except 244 - dcache tag exception 2 was not recieved when 

expected 

exception bit set in tag but not in GTLB - rhodan /s3 6395.2961 
trying to re-create with dcacheharderS 

unix_l 250 - Looks like the test resets the machine 

cerberrtest 247 - X trace on nosferatu /s2 83 95.16920 

cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 

Performance Failures (Test ran to completion but failed performance 
measure) 


dcache_perf_ldlt_l Expected difference between the cached and 

non-cached access = 4600-5050 cycles 

Actually took 3 650 fewer cycles rhodan /s3 242 95.82 6 0 
icache_perf_lt_l Expected difference between the cached and 
non- cached access = 4600.0-50600 cycles 

Actually took 123 800 fewer cycles rhodan /s3 

26295 . 14314 

icache_perf_5t_l Expected difference between the cached and 
non-cached access = 58000-63800 cycles 

Actually took 117120 (!) fewer cycles rhodan /s3 

6395 .3461 

nb_l Actual accept time = 160:186 Expected accept time 

= 150:180 rhodan /s3 28295.4379 

nb_slow Actual accept time = 160:186 Expected accept time 

= 150:180 rhodan /s3 28295.4379 

Have not yet been run: 

hermes_load_0 

nb_combo_l 

her me s_conf lie t_l 

ruptpintest_0 - Need to build a "custom" simulator 

inter leave_U 
except ion_U 
tlb_U 
synch_U 
instr_U 

Cannot yet be run: 
nulltest 
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xlu tests 


xlu_rotate_l_l 

xlu_rotate_2_l 

xlu_expand_l_l 

xlu_compress_l_l 

xlu_extract_l_l 

xlu_field_l_l 

xlu_f ield_2_l 

xlu_field_3_l 

x 1 u_c opy s wap_l_l 

x 1 u_c opy s wap_2 _l 

xl u_c opy s wap_3 _l 

x 1 u_c opy s wap_4 __1 

xlujshuf f lemux_l_l 

xlu_select_l_l 

Not yet implemented: 


brcolltest_0 

brcrosstest_0 

brimmlongtest_0 

expriotest_0 

canceltest_0 

hermtotest_0 

cerbtotest_0 

hermerrtest_0 

eventregtest_0 

exintbashtest_0 

cerberror_0 

testerinit_0 

memmap_0 

nbbashtest_0 

cerbarbtests 

hcplltests 

addr_mad_void 
addr_map_mc 
addr_map_c erb 
addr_map_herme s 

node -boot 
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From: woody (Jay Tomlinson) 

Sent: Tuesday, March 1 4, 1 995 1 1 :52 AM 

To: 'tbr'; 'dbulfer'; 'wayne' 

Subject: Review of the Pandora Euterpe Module schematic 


Let's meet at 2pm in the Engineering Conf room to review the Pandora Euterpe 
Module schematic. I will distribute copies of the schematic prior to the 
meeting. 

thanks, 

woody 
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From: 
Sent: 
To: 


Subject: 


billz {Bill Zuravleff) 

Tuesday, March 14, 1995 1:58 PM 

'tbr (Tim B. Robinson)'; 'mws (Mark Semmelmeyer)'; 'dickson (Richard Dickson)'; 'wampler 
(Kurt Wampler)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)' 
PCOMP fails, why? 


Y'all, 


the "pcomp" step in my place and route sequence fails (it worked this morning, I 
thought) . Any idea why this is? 

A partial error messages follows. Complete listings in 
~billz/euterpe/verilog/bsrc/nb/nbgards. log and the nb/gards directory. 


GARDS PCOMP 7.121 -- Physical Compiler 

Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: nb-passl Started at: 95/03/14 18:40:15 

PCOMP Version 7.1.21 of August 9, 1994 

Processing Logic description: NB 
Processing Expansion level: SLNET 

... Start of netlist processing. 

. . . Circuit name : NB 

. . . Processing CDL. 

... CHIPNAME : SOFA; 


. . . Processing header of user PDL. 

. . . PH YS I CALL I B : PBUILD ; 

. . . Processing header of system PDL. 

. . . PHYSICALLIB : PBUILD; 
. . . Processing rest of user PDL. 
In EAMEMA1R1W6X1A at line 9175: 
- - > TARGETNET : RWL_AB 1 PE F < 0 > ; 

t 

** Syntax Error: Pin name RWL_AB1PEF<0> is not on the corresponding logical type. 
(Message number 35 Severity 5) 

In EAMEMA1R1W6X1A at line 9181: 
- - > TARGETNET : WWL_AB1PF< 0 > ; 


Thanks , 
billz 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, March 14, 1995 3:08 PM 

To: 'torn (Tom Laidig)'; 'ong (Warren R. Ong)'; 'fwo (Fred Obermeier) 1 ; 'geert (Geert Rosseel)' 

Cc: 'tbr (Tim B. Robinson)'; 'billz (Bill Zuravleff)' 

Subject: Re: PCOMP fails, why? 


Tim B. Robinson writes: 

Bill Zuravleff wrote (on Tue Mar 14) : 

Y'all, 

the "pcomp" step in my place and route sequence fails 
(it worked this morning, I thought) . Any idea why this is? 

A partial error messages follows. Complete listings in 
-bill z/euterpe/verilog/bsrc/nb/nbgards . log and the nb/gards 

directory. 

Thanks , 
billz 


GARDS PCOMP 7.121 -- Physical Compiler 

Copyright (c) 1995 SILVAR-LISCO . All rights reserved. 
Design: nb-passl Started at: 95/03/14 18:40:15 

PCOMP Version 7.1.21 of August 9, 1994 

Processing Logic description: NB 
Processing Expansion level: SLNET 

... Start of netlist processing. 

. . . Circuit name: NB 

. . . Processing CDL. 

... CHIPNAME : SOFA; 


. . . Processing header of user PDL. 

. . . PHYSICALLIB : PBUILD ; 

. . . Processing header of system PDL. 

. . . PHYSICALLIB : PBUILD ; 

. . . Processing rest of user PDL. 

In EAMEMA1R1W6X1A at line 9175: 

--> TARGETNET : RWL_AB1 PEF< 0 > ; 

I 

** Syntax Error: Pin name RWL_AB1PEF<0> is not on the corresponding 
logical type. 

(Message number 35 Severity 5) 

In EAMEMA1R1W6X1A at line 9181: 
- - > TARGETNET : WWL_AB 1 PF< 0 > ; 

! 

There has been some sort of update going on with ea cells. It looks 
like the PDL is out of sync with the netlist. That couls be because 

the 

update had not completed when you ran, or it could be because the 
verilog library model is not out of sync with the layout 

Tim 

We've seen this for a day or so now. 

Warren did these pin names change? I don't think so. 
I'm not sure what's going on. 

The chipq is currently empty, so there are no updates in progress. 
We need to track this down. 

Tom- are all PDLs up-to-date by your reckoning? 
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I wonder if this is a schematic vs. layout problem 
-hopper 
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To: 

Subject: 


Sent: 


From: 


tbr 

Tuesday, March 14, 1995 3:42 PM 
'billz' 

euterpe. status 


Follow Up Flag: Follow up 
Flag Status: Red 


I added a description of the DRAM overrun problem we expect to have 
when the clock ration is below 10. Could you reproduce the formula 
you had so we can specify the general case, ie, assuming we can 
select both dram an hermes clock ratios, what is the inequality that 
has to hold to guarantee it works in the worst case? 


Thanks 
Tim 
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From: biflz (Bill Zuravleff) 

Sent: Tuesday, March 14, 1995 5:48 PM 

To: 'tor 1 

Subject: Re: euterpe. status 
Could you reproduce the formula 

you had so we can specify the general case, ie, assuming we can 
select both dram an hermes clock ratios, what is the inequality that 
has to hold to guarantee it works in the worst case? 

OK. Done. I think. I hope "Ratio >= 10" isn't too simplistic. I'm 
sure you'll let me know if the explanation is inadequate. 

Regards, 
billz 
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From: tbr 

Sent: Tuesday, March 14, 1995 7:47 PM 

To: Vanthof (vant)' 

Cc: 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'Dave Van't Hof; 

Tom Vo' 

Subject: mnemo drc's finished 

Follow Up Flag: Follow up 
Flag Status: Red 


vant wrote (on Tue Mar 14): 


The mnemo upper drc's have finished and aside some notch errors in the 
metals from the router and via twinner, the metals are clean. 

The lowers are basically clean EXCEPT for 5 big holes in the poly layer: 

93560, 6000 
93720, 6000 
67680, 5520 
69840, 5520 
178560,5520 

The floating poly check died when it filled up the disk. Is it possible to 
have larger than 2GB partitions on sunos? We've reached the point where 
a single stage within a dracula run for mnemo exceeds the current file 
system sizes created for dracula jobs. These are currently about 1 .6GB and 
it would be nice to have about 3GB per partition. 

There is a product from sun which should do this. It's $825 for a 
single system license. I need to confirm it will run with 4. 1 .3. 
If so, I'll see how soon we can get it. 

I'll manually fix and restart the floating poly check. 
Tim 
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To: 

Cc: 

Subject: 


Sent: 


From: 


tbr 

Tuesday, March 14, 1995 7:54 PM 

'pmayer' 

'woody' 

Euterpe board 


Follow Up Flag: Follow up 
Flag Status: Red 

In reviewing the schematic today we realized we were missing the DC 
power connector. Do you already have a part footprint for that? I don't know 
the part number, but jay was going to dig out the specs. 


Tim 
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From: pmayer (Patricia Mayer) 

Sent: Tuesday, March 14, 1995 8:20 PM 

To: tor' 

Cc: 'woody'; 'pmayer' 
Subject: Re: Euterpe board 

I don't recall any special connector other than the straddle 
mount. 

Pattie 

> From tbr Tue Mar 14 16:54:02 1995 

> Date: Tue, 14 Mar 1995 16:53:59 -0800 

> From: tbr (Tim B. Robinson) 

> To: pmayer 

> Cc: woody 

> Subject: Euterpe board 

> Content-Length: 212 
> 

> 

> In reviewing the schematic today we realized we were missing the DC 

> power connector. Do you already have a part footprint for that? I don't know 

> the part number, but jay was going to dig out the specs. 

> 

>Tim 

> 
> 
> 
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From: 


tbr 


Sent: 
To: 

Subject: 


Tuesday, March 14, 1995 9:43 PM 

'woody' 

ged compile 


Follow Up Flag: Follow up 
Flag Status: Red 

I tried again and it still fails. The .1st file has 

#1 ERROR(47) Wrong description in libraries for part 

PIN_NUMBER Syntax error: Number of sections in line 13 
Filename : Yn/auspex/slO/chip/morpheus/geaVcustom/euterpe/chips_prt' 

Is there still somethng that needs to be released to /u/chip? 


Tim 
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From: tbr 

Sent: Tuesday, March 14, 1995 10:00 PM 

To: 'billz (Bill Zuravleff)' 

Cc: 'dickson (Richard Dickson)'; 'brianl'; 'ong'; 'geert (Geert Rosseel)'; 'Mark HofmanrY; 'Mark 

Semmelmeyer'; 'Kurt Wampler' 

Subject: PCOMP fails, why? 

Follow Up Flag: Follow up 

Flag Status: Red 


Bill Zuravleff wrote (on Tue Mar 14): 


Y'all, 

the "pcomp" step in my place and route sequence fails 
(it worked this morning, I thought). Any idea why this is? 
A partial error messages follows. Complete listings in 
-billz/euterpe/verilog/bsrc/nb/nbgards.log and the nb/gards 
directory. 

Thanks, 
billz 


GARDS PCOMP 7.121 -- Physical Compiler 
Copyright (c) 1995 SILVAR-LISCO. All rights reserved. 
Design: nb-passl Started at: 95/03/14 18:40:15 

PCOMP Version 7.1.21 of August 9, 1994 

Processing Logic description: NB 
Processing Expansion level: SLNET 

... Start of netlist processing. 
... Circuit name: NB 
... Processing CDL. 
... CHIPNAME: SOFA; 


... Processing header of user PDL. 
... PHYSIC ALLIB:PBUILD; 
... Processing header of system PDL. 
... PHYSICALLIB:PBUILD; 
... Processing rest of user PDL. 
In EAMEMA1R1 W6X1A at line 9175: 
--> TARGETNET:R WLAB 1 PEF<0>; 
» 

** Syntax Error: Pin name RWL_AB 1 PEF<0> is not on the corresponding 
logical type. 

(Message number 35 Severity 5) 

In E AMEM A 1 R 1 W6X 1 A at line 9181: 
-> TARGETNET:WWL_AB1PF<0>; 
! 
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There has been some sort of update going on with ea cells. It looks 
like the PDL is out of sync with the netlist That couls be because the 
update had not completed when you ran, or it could be because the 
verilog library model is not out of sync with the layout 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, March 14, 1995 10:00 PM 

•billz (Bill Zuravleff)' 

'dickson (Richard Dickson)'; 'brianl'; 'ong'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 
'mws (Mark Semmelmeyer)'; 'wampler (Kurt Wampler)' 
PCOMP fails, why? 


Bill Zuravleff wrote (on Tue Mar 14) : 


Y'all, 

the "pcomp" step in my place and route sequence fails 
(it worked this morning, I thought) . Any idea why this is? 
A partial error messages follows. Complete listings in 
~billz/euterpe/verilog/bsrc/nb/nbgards.log and the nb/gards 
directory. 


GARDS PCOMP 7.121 -- Physical Compiler 

Copyright (c) 19 95 SILVAR-LISCO . All rights reserved. 
Design: nb-passl Started at: 95/03/14 18:40:15 

PCOMP Version 7.1.21 of August 9, 1994 

Processing Logic description: NB 
Processing Expansion level: SLNET 

. . . Start of netlist processing. 

. . . Circuit name: NB 

. . . Processing CDL. 

. . . CHIPNAME : SOFA; 


... Processing header of user pdl. 

. . . PHYSICALLIB : PBUILD ; 

... Processing header of system PDL. 

... PHYSICALLIB : PBUILD ; 

. . . Processing rest of user PDL. 

In EAMEMA1R1W6X1A at line 9175: 

- - > TARGETNET : RWL_AB 1 PE F < 0 > ; 

** Syntax Error: Pin name RWL_AB1PEF<0> is not on the corresponding 
logical type. 

(Message number 3 5 Severity 5) 

In EAMEMA1R1W6X1A at line 9181: 
--> TARGETNET : WWL_AB 1 PF< 0 > ; 


There has been some sort of update going on with ea cells. It looks 
like the PDL is out of sync with the netlist. That couls be because the 

update had not completed when you ran, or it could be because the verilog library model is 
not out of sync with the layout 


Thanks , 
billz 


Tim 
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From: geert (Geert Rosseel) 
Sent: Tuesday, March 14, 1 995 1 1 :22 PM 
To: 'brianl'; 'fwo'; 'hopper'; 'tbr 1 ; 'torn' 
Subject: snapshot getbom in trouble .. 

Brainl is doing a getbom in the euterpe snashot and I see in the 
log file: 

cvs status: [19:58:28] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacro 
cvs status: [19:58:58] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacro 
cvs status: [19:59:28] waiting for chip's lock in /p/cvsroot/proteus/geaVpl/cpllmacro 
cvs status: [19:59:58] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacro 
cvs status: [20:00:28] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpltmacro 
cvs status: [20:00:58] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacro 
cvs status: [20:01:28] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacro 
cvs status: [20:01:58] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacro 
cvs status: [20:02:28] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacro 
cvs status: [20:02:58] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacro 

Geert 
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From: tbr 

Sent: Wednesday, March 15, 1995 12:10 AM 

To: 'hopper (Mark Hofmann)' 

Cc: 'billz (Bill Zuravleff)'; 'fwo (Fred Obermeier)'; 'geert (Geert Rosseel)'; 'Warren R. Ong'; 'Tom 

Laidig' 

Subject: Re: PCOMP fails, why? 

Follow Up Flag: Follow up 
Flag Status: Red 


Mark Hofmann wrote (on Tue Mar 14): 

We've seen this for a day or so now. 

Warren did these pin names change? I don't think so. 

I'm not sure what's going on. 

The chipq is currently empty, so there are no updates in progress. 

We need to track this down. 

Tom- are all PDLs up-to-date by your reckoning? 

I wonder if this is a schematic vs. layout problem 

1 thought fred had initiated some pin name changes to fix euterpe csyn 
errors. 

Tim 
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From: tbr (Tim B. Robinson) 

Sent: Wednesday, March 15, 1995 12:10 AM 

To: 'hopper (Mark Hofmann)' 

Cc: 'billz (Bill Zuravleff)'; 'two (Fred Obermeier)'; 'geert (Geert Rosseel)'; 'ong (Warren R. Ong)'; 

'torn (Tom Laidig)' 
Subject: Re: PCOMP fails, why? 


Mark Hofmann wrote (on Tue Mar 14) : 

We've seen this for a day or so now. 

Warren did these pin names change? I don't think so. 
I'm not sure what's going on. 

The chipq is currently empty, so there are no updates in progress. 
We need to track this down. 

Tom- are all PDLs up-to-date by your reckoning? 

I wonder if this is a schematic vs. layout problem 

I thought fred had initiated some pin name changes to fix euterpe csyn errors. 

Tim 
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From: woody (Jay Tomlinson) 

Sent: Wednesday, March 15, 1995 12:21 AM 

To: 'tbr (Tim B. Robinson)' 

Cc: 'pmayer' 

Subject: Euterpe board 

Tim B. Robinson wrote (on Tue Mar 14): 

In reviewing the schematic today we realized we were missing the DC 
power connector. Do you already have a part footprint for that? I don't know 
the part number, but jay was going to dig out the specs. 

Tim 


I dropped off a copy of the spec on pattie's chair. It did not contain the 
partnumber, I will check with vijay. 

woody 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Wednesday, March 15, 1995 12:31 AM 
■geert (Geert Rosseel)' 
'brianl'; 'fwo'; 'hopper'; 'torn' 
snapshot getbom in trouble .. 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Tue Mar 1 4): 

Brainl is doing a getbom in the euterpe snashot and I see in the 
log file : 

cvs status: [19:58:28] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacro 


I don't inderstand why chip would be holding that lock unless an 
earlier attempt got killed ungracefully: 

tbr@aphrodite/u/chip/chip-archive/proteus/ged/pl/cpllmacrol 405 % Is -Is 
total 47 

1 drwxr-sr-x 2 chip 512 Mar 14 17:50 #cvs.Iock 

1 drwxrwsr-x 3 rich 5 12 Mar 14 17:50 . 

2 drwxrwsr-x 71 tom 2048 Mar 14 17:50 .. 
2 _ r -. r __r- 1 rich 171 1 Mar 25 1994 BOM,v 

5 -r-r-r- 1 rich 48 1 0 Mar 25 1 994 body. I.l,v 
28-r-r-r-- 1 rich 27849 Mar 25 1994 spice. 1.1 ,v 
8 -r-r-r-- 1 rich 7923 Mar 25 1994 spice_cn. 1.1, v 

I removed the lock, but the new getbom seems to be stuck 
because the last entry in the log is incomplete and from a while ago. 

cvs status: [20:49:34] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacrol 
cvs status: [20:50:04] waiting for chip's lock in /p/cvsroot/proteus/ged/pl/cpllmacrol 
cvs status: [20:50:34] waiting for chip's lock in /p/cvsroot/proteus/ 

It does not seem to have woken up since I removed the lock. 
Which machine is the getbom running on? 


Tim 
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From: tbr (Tim B. Robinson) 

Sent: Wednesday, March 15, 1995 12:31 AM 

To: 'geert (Geert Rosseel)' 

Cc: 'brianl'; 'two'; 'hopper'; 'torn' 

Subject: snapshot getbom in trouble .. 


Geert Rosseel wrote (on Tue Mar 14) : 


Brainl is doing a getbom in the euterpe snashot and I see in the 
log file : 

cvs status: [19:58:28] waiting for chip's lock in /p/cvsroot /proteus/ged/pl/cpllmacro 
1 

I don't inderstand why chip would be holding that lock unless an earlier attempt got 
killed ungracefully: 

tbr@aphrodite /u/chip/chip-archive/proteus/ged/pl/cpllmacrol 4 05 % Is -Is total 4 7 
1 drwxr-sr-x 2 chip 512 Mar 14 17:50 #cvs.lock 

1 drwxrwsr-x 3 rich 512 Mar 14 17:50 . 

2 drwxrwsr-x 71 torn 2048 Mar 14 17:50 .. 

2 - r --r--r-- 1 rich 1711 Mar 25 1994 BOM,v 

5 - r --r--r-- 1 rich 4810 Mar 25 1994 body.l.l,v 

28 - r --r--r-- 1 rich 27849 Mar 25 1994 spice. 1.1, v 

8 - r -- r -_ r __ i rich 7923 Mar 25 1994 spice_cn . 1 . 1 , v 

I removed the lock, but the new getbom seems to be stuck because the last entry in the log 
is incomplete and from a while ago. 

cvs status: [20:49:34] waiting for chip's lock in 
/p/cvsroot /proteus/ged/pl/cpllmacrol 
cvs status: [20:50:04] waiting for chip's lock in 
/p/cvsroot /proteus/ged/pl/cpllmacrol 

cvs status: [20:50:34] waiting for chip's lock in /p/cvsroot/proteus/ 

It does not seem to have woken up since I removed the lock. 
Which machine is the getbom running on? 

Tim 
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From: woody {Jay Tomlinson) 

Sent: Wednesday, March 15, 1995 12:35 AM 

To: 'tbr (Tim B. Robinson)' 

Subject: ged compile 


Tim B. Robinson wrote (on Tue Mar 14): 

I tried again and it still fails. The .1st file has 

#1 ERROR(47) Wrong description in libraries for part 

PIN_NUMBER Syntax error: Number of sections in line 1 3 

File name : Vn/auspex/slO/chip/morpheus/ged/custom/euterpe/chips^rt' 

Is there still somethng that needs to be released to /u/chip? 

Tim 

This problem is due to the fact that dan has not yet released his new tool for 
generating chips_prt. I have a chips_prt in my dir that will work, but 
/u/chip/morpheus will generate the wrong thing. I should have remembered this 
earlier. Until this tool is released, I think you are stuck unless you want to 
check out and build morphues/ged, morpheus/gyg, and morpheus/verilog. Although 
gyg does not build completely because of missing pcad .prt files. Is there any 
reason to keep this stuff? Minimally, I think we can remove the default rules 
that package the pcad parts. 

I just released morpheus/slibsrc, but the chips _prt error will prevent you from 
getting that far. 

woody 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Wednesday, March 15, 1995 12:42 AM 

•geert' 

'wampler' 

gt 


Follow Up Flag: Follow up 
Flag Status: Red 


My new gt placement has converged. Looks to be 300 atoms smaller, and 
it now fits between the spars, though it does use one more row. 
Before I release it I'd like to try my mini top level route just to 
make sure it looks OK too. 

I do see a couple of anomalies which I think we need to understand. 
The router has put int some metal 2 nets which form trombones across 
the RH clock spar and back for no apparant reason. Kurt, can you take 
a look at this in ~tbr/euterpe/verilog/bsrc/gt/gards/gt-iter.dff? 


Tim 


Exhibit C12 


Page 256 of 643 


Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, March 15, 1995 12:42 AM 

'geert' 

'wampler' 

gt 


My new gt placement has converged. Looks to be 3 00 atoms smaller, and it now fits between 
the spars, though it does use one more row. 

Before I release it I'd like to try my mini top level route just to make sure it looks OK 
too. 

I do see a couple of anomalies which I think we need to understand. 

The router has put int some metal 2 nets which form trombones across the RH clock spar and 
back for no apparant reason. Kurt, can you take a look at this in 
~tbr/euterpe/verilog/bsrc/gt/gards/gt-iter .df f ? 


Tim 
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From: 


tbr 


Subject: 


Sent: 


To: 


Wednesday, March 15, 1995 12:44 AM 
'woody (Jay Tomlinson)' 
ged compile 


Follow Up Flag: Follow up 
Flag Status: Red 

Jay Tomlinson wrote (on Tue Mar 14): 


Tim B. Robinson wrote (on Tue Mar 14): 

I tried again and it still fails. The .1st file has 

#1 ERROR(47) Wrong description in libraries for part 

PIN NUMBER Syntax error: Number of sections in line 1 3 

File name : Yn/auspex/slO/chip/morpheus/ged/custom/euterpe/chips_prt' 

Is there still somethng that needs to be released to /u/chip? 

Tim 

This problem is due to the fact that dan has not yet released his new tool for 
generating chips_prt. I have a chips_prt in my dir that will work, but 
/u/chip/morpheus will generate the wrong thing. I should have remembered this 
earlier. Until this tool is released, I think you are stuck unless you want to 
check out and build morphues/ged, morpheus/gyg, and morpheus/verilog. Although 
gyg does not build completely because of missing pcad .prt files. Is there any 
reason to keep this stuff? Minimally, I think we can remove the default rules 
that package the pcad parts. 

I think it would be fine to disable the make of the pcad stuff. 

I just released morpheus/slibsrc, but the chips _prt error will prevent you from 
getting that far. 

Please send a note to dan asking him to release this stuff. I'd 
prefer to wait till I can do it without cheating. 


Tim 
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From: warn pier (Kurt Warn pier) 

Sent: Wednesday, March 15, 1995 12:48 AM 

To: 'geert' 

Cc: 'billz'; 'dickson'; 'hopper'; 'rows'; 'tor'; 'vo'; 'wampler'; 'woody' 

Subject: Re: Descending netlength linesearch completed 


Wampler wrote: 

>My descending netlength linesearch route completed: 3,590 disconnects. 
Most 

>of the disconnects are short nets, with the exception of some long-haul 
stuff 

>coming out of the left & right corridors . 
> 

>l've started maze routing to see how successful it is at finishing up 
>the short stuff now that all the long wires are in place. I expect a 
>result late tomorrow morning. 


Looks like the maze route ran pretty fast (about 4 hrs) indicating that 
it runs a lot faster on short nets than on long ones. There are 850 
disconnects after maze routing; not the kind of improvement we were 
hoping for. 

I think 850 is too large a number to feed to the rip -up router; it probably 
disturbs (and degrades) at least 5 other wires for every unroute that it 
solves, so we really want to avoid using it at all if we can. 850 
would also be a heroic number to solve by hand in REDIT. 

The two dff 's can be found in /n/godzilla/s2 /wampler /invroute if you want 
to poke around: 

geert_euterpe- iter . dff . linesearch (3590 disconnects after linesearch) 
geert_euterpe-iter . df f ( 850 disconnects after maze) 

The remaining unroutes are somewhat of a hodgepodge of short & long nets; 
some of them are definitely busses that were part of our "early routing" 
list. 


Kurt 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, March 1 5, 1 995 1 2:59 AM 

To: 'billz* 

Cc: 'dickson'; 'jeffm'; 'tbr'; 'veena' 
Subject: stgen dump 

Is ready .. it is on staypuft/s3/tbr/euterpe/verilog/bsrc. 
Lisa R. 
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From: wampler (Kurt Wampler) 

Sent: Wednesday, March 15, 1995 1:09 AM 

To: "geerf; 'tor' 

Subject: Re: gt 

Tbr writes: 


>My new gt placement has converged. Looks to be 300 atoms smaller, and 
>it now fits between the spars, though it does use one more row. 
>Before I release it I'd like to try my mini top level route just to 
>make sure it looks OK too. 

Good progress! 

>I do see a couple of anomalies which I think we need to understand. 
>The router has put int some metal 2 nets which form trombones across 
>the RH clock spar and back for no apparant reason. Kurt, can you take 
>a look at this in ~tbr/euterpe/verilog/bsrc/gt/gards/gt-iter.dff? 

These all look suspiciously like they were accomplished during the 
metal2 maze pass at the beginning of routing. It looks like the router 
is obeying the constraints we have given it. If we don't want the router 
to be able to thread wires through the clock spars, we could add some M2 
obstructions on the left- and right-hand edges of each clock spar to 
prevent this. But if it's legal and it meets timing, why not permit 
it to do what it's doing? It uses no M3 or M4 resource to do this hookups 
and that's probably a win in terms of routing congestion. 

-Kurt 


Exhibit C12 


Page 261 of 643 


From: 
Sent: 
To: 


Subject: 


Cc: 


tbr 

Wednesday, March 15, 1995 1:13 AM 
'wampler (Kurt Wampler)' 
'geert' 
Re: gt 


Follow Up Flag: Follow up 
Flag Status: Red 

Kurt Wampler wrote (on Tue Mar 14): 
Tbr writes: 


>My new gt placement has converged. Looks to be 300 atoms smaller, and 
>it now fits between the spars, though it does use one more row. 
>Before I release it I'd like to try my mini top level route just to 
>make sure it looks OK too. 

Good progress! 

>I do see a couple of anomalies which I think we need to understand. 
>The router has put int some metal 2 nets which form trombones across 
>the RH clock spar and back for no apparant reason. Kurt, can you take 
>a look at this in ~tbr/euterpe/verilog/bsrc/gt/gards/gt-iter.dff? 

These all look suspiciously like they were accomplished during the 
metal2 maze pass at the beginning of routing. It looks like the router 
is obeying the constraints we have given it. If we don't want the router 
to be able to thread wires through the clock spars, we could add some M2 
obstructions on the left- and right-hand edges of each clock spar to 
prevent this. But if it's legal and it meets timing, why not permit 
it to do what it's doing? It uses no M3 or M4 resource to do this hookups 
and that's probably a win in terms of routing congestion. 

I agree so long as we understand it and it makes timing it's probably 
harmless. My main concern would be if these popped up later at the 
top level and the significant extra metal 2 then meant we needed to 
power up. 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, March 15, 1995 10:1 1 AM 

To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr'; 'woody' 

Cc: 'doi'; 'geert' 

Subject: Test status 

BOM 247 running on Zycad 
BOM 253 running on IKOS 

New business 


I ran some of the tests that failed in verilog and the following dumps are availble: 

icache_stress 253 - X rhodan /s3/euterpe/verilog/bsrc 

synch ! 253 - This went to X on the Ikos but is hung in this one. 

aphrodite /s3/euterpe/verilog/bsrc 
xlu„field_4 253 - This hung and I didn't notice (expecting it to go to X) 

before I blew away the dump. I am re-running on nosferatu 
/s5/euterpe/verilog/bsrc. I did save the wrap, log called 
wrap.logxlu_field_4 it hung around 10% through. 


Next group on rhodan /s3 13395.100: 

mem U 253 - Ran ok 

bgateU 253 - Understood 

barreMJ 253 - Shows same failure as stgen 

interrupt__U Need to re-run 

gtlb_miss_U 253 - Shows same failure as stgen 

cache_U 252 - X traces on rhodan /s3 likedriverlog 5395.1338 vldUV^debug 10395.25580 

prblm_debug 14395.107 

sync_ 1 253 - X rhodan /s3 1 0395 .25253 cache_debug vldU V_debug 1 43 95 . 326 

icachenoallocj) 252 - Hung rhodan /s3 13395. 1 9696 sump on staypuft /s5/tbr/euterpe 

stgenrl 33 1 1_0 240 - Miscompare trace on nosferatu /s4/res/3 395. 13608 
250 - New dump on staypuft /s3/tbr/euterpe/verilog/bsrc with dr 

atomic_conflict_l 250 - rhodan /s3 1 1395.6066 

Thread 3, Reg 0, Param Entry 2 Expected 1020304050607 Got baadbeefbaadbeef 

xlu_field_4_l 250 - X (Ran for much longer) rhodan /s3 1 1 395.5887 

dcache_perf_stlt_l 250 - Cache Data Error Expected 200000000000, Got 200000000000 Expected 200000000080, Got 
200000000080 

Expected 200000000108, Got 200000000108 Expected 200000000 ld8, Got 200000000 ld8 

Expected 200000000f¥8, Got 200000000ff8 
dcache_perf_ldst5t_l 250 - Exxxexpppcpeeetecccectttdteee edddd 
200020220200000000000000000004000010000000004000041,4401 1 1000 ,G„, o 
You get the picture! Traces for both on rhodan /s3 1 1395.2390 

dcache_conflict_l 250 Thread 3, Reg 1, Param Entry 2 Expected 1020304050607 Got ffffdffffiri-ffff - trace on 
rhodan /s3 11395.6701 


icachejjtress 249 - X /s3 rhodan 10395.8826 (and 6395.2961) and 10395.24485 snake_debug 
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nb_hermes_l 247 - nosferatu /s2 1 0395.50 1 7 

hermesloadj) 247 - hermes model problem 


instr_l 25 1 - X } rhodan /s3 12395. 1 1 603 

insnj 251 -X} 

tlb_l 250 - X rhodan /s3 1 1395.6933 

interleave^ 247 - X and doesn't enable hermes (comment in log says otherwise?) nosferatu /s2 1 1 395. 1 5228 
Old Business - Need to reun and if necessary redump these 
hermes lateturnon 241 - understood 
Recreated with icachenoalloc 

icache_func_l 244 - trace on rhodan /s3 5395.2288 (hung) 
251 - rhodan /s3 12395.13205 hung 


dcache_except 244 - dcache tag exception 2 was not recieved when expected 
exception bit set in tag but not in GTLB - rhodan /s3 6395.2961 
trying to re-create with dcacheharder5 

unix_l 250 - Looks like the test resets the machine 

cerberrtest 247 - X trace on nosferatu /s2 8395 . 1 6920 


cerbarbeasy_0 Lisa R to run again as verilog run is well behaved 
Performance Failures (Test ran to completion but failed performance measure) 


dcache_perf_ldlt_l Expected difference between the cached and non-cached access = 4600-5050 cycles 

Actually took 3650 fewer cycles rhodan /s3 24295.8260 
icache_perf_lt_l Expected difference between the cached and non-cached access = 46000-50600 cycles 

Actually took 123800 fewer cycles rhodan /s3 26295 . 1 43 1 4 
icache_perf_5t_l Expected difference between the cached and non-cached access = 58000-63800 cycles 

Actually took 1 17120 (!) fewer cycles rhodan /s3 6395.3461 
nb_l Actual accept time = 160:1 86 Expected accept time = 150:1 80 rhodan /s3 28295.4379 

nb_slow Actual accept time = 160: 1 86 Expected accept time = 1 50: 1 80 rhodan /s3 28295.4379 


Have not yet been run: 


hermes_load_0 
nbcombol 
hermes_conflict_ 1 

ruptpintest_0 - Need to build a "custom" simulator 

interleave_U 

exception_U 

tlbU 

synch_U 

instrU 


Cannot yet be run: 


nulltest 


XLU tests 

xlurotatell 
xlu_rotate__2_l 
xlu_expand_l_l 
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xlu_compress_l_l 

xhi_extract_l_l 

xlujieldjj 

xlu_field_2_l 

xlu_field_3_l 

xlu_copyswap_l_l 

xhi_copy swap_2_ 1 

xlu copyswap_3_ 1 

xlu_copy swap_4_ 1 

xlu shufflemux_] _! 

xlu_select_l_l 

Not yet implemented: 


brcolltestj) 

brcrosstest_0 

brimmlongtest 0 

expriotestj) 

canceltest_0 

hermtotest_0 

cerbtotest_0 

hermerrtest_0 

everitregtest_0 

exintbashtest_0 

cerberror_0 

testerinit_0 

mem map 0 

nbbashtestO 

cerbarbtests 

hcplltests 

addr_mad_void 
addrniap_mc 
addr_map_cerb 
addrmapherm es 

node-boot 
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From: woody (Jay Tomlinson) 

Sent: Wednesday, March 15, 1995 11:06 AM 

To: 'philip' 

Cc: 'pmayer'; 'tor'; 'vijay' 

Subject: Euterpe board 

Philip, 

Have a partnumber been assigned for the DC power connnector that is used on the 
pandora euterpe module? 

woody 
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From: philip@microunity.com 

Sent: Wednesday, March 1 5, 1 995 1 2 : 1 6 PM 

To: 'woody (Jay Tomlinson)' 

Cc: 'pmayer 1 ; 'tbr'; Vijay' 

Subject: Re: Euterpe board 

At 8:05 AM 3/15/95 -0800, Jay Tomlinson wrote: 
>Philip, 

> 

>Have a partnumber been assigned for the DC power connnector that is used on the 
>pandora euterpe module? 

> 

>woody 

Yes, they have. The part numbers have been assigned to both a socket and plug. 

My belief is that the plug will be mounted on the Euterpe module (because 
it is a right angle part). The part number is : 

370-00041-0000 CONN PWR PLUG RGT ANGL PANDORA 

Regards 
Philip 
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From: solo (John Campbell) 

Sent: Wednesday, March 15, 1995 12:24 PM 

To: 'tbr (Tim B. Robinson)' 

Cc: 'lisar (Lisa Robinson)* 

Subject: Found where it has been. 

looks like it is still ticking but all too slow, seems to be ticking 
but chip is taking 47% of the cpu for spice simulations, all other 
machines are finished with leafmold. mercury has 20 layouts to go out 
of 309. maybe an improvement here might be to dynamically distribute 
the load to the machines, maybe give them 20 at a time and come back 
for more when you are done, later though, other machines have been 
finished for only 1-1.5 hours so maybe not too bad. 

solo@mercury ~ 56 % ps -auxw | grep solo 

solo 29678 0.0 0.6 172 396 pb R 09:14 0:00 ps -auxw 

solo 29671 0.0 0.0 1008 0? DN 09:14 0:03 <exiting> 

solo 29679 0.0 0.3 32 180pbS 09:14 0:00 grep solo 

solo 3128 0.0 0.0 28 0 ? I W 19:32 0:00 sh 

solo 29397 0.0 0.2 40 96? IN 09:12 0:00 /bin/sh ./leafmold -r -c 

xbmuxen7dh 12s.wire /n/nosferatu/s3/proteus/proteus/ 

solo 3120 0.0 0.0 200 0?IW 19:32 0:00 tcsh -csh 

solo 3130 0.0 0.0 1648 0 ? IWN 19:32 0:31 gmake -wk CELL_LIST=tmp. list mercury leaf-layouts 

solo 29385 0.0 0.0 32 0? IWN 09:12 0:00 /bin/sh ./leafmold -qr -c 

xbmuxen7dh 1 2 s .wire /n/nosferatu/s3 /proteus/proteus 

solo 29384 0.0 0.0 28 0 ? IWN 09:12 0:00 /bin/sh -c 

solo 28095 0.0 0.7 316 448 pb S 09:02 0:01 -tcsh (tcsh) 

solo 28288 0.0 1.8 248 1100 pbS 09:04 0:00 xload 

solo 29670 0.0 0.6 64 384? IN 09:14 0:00 /bin/csh /usr/tmp/leafmold.xbmuxen7dhl2s/sl/bin/slnet leaf 
solo@mercury - 57 % 


regards, 

solo a.k.a. John Campbell x5 16 

f- 
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Subject: 


Sent: 

To: 

Cc: 


From: 


fwo (Fred Obermeier) 

Wednesday, March 15, 1995 12:47 PM 

W 

'billz'; 'fwo'; 'geert'; 'hopper'; 'ong'; 'torn' 
Re: PCOMP fails, why? 


Yes, I have initiated pin name changes to help fix a lot of csyn errors on euterpe. 
However, I also have not been able to get a build of f wo_euterpe-passl . spivs in bsrc since 
then. There seems to be some Makefile problem. It's always been something over the last 
few days . 

The verilog models got updated on March 10th. See files in 

/u/chip/proteus/verilog/elib/eamem*v. I sent Tim some email after that happened 
requesting that he include these updated verilog files into to the snapshot. Maybe the 
timing files need to be included with the snapshot too, if they are done. 


Fred. 
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From: wampler (Kurt Wampler) 

Sent: Wednesday, March 1 5, 1 995 1 :05 PM 

To: 'geert' 

Subject: FWD: RE: hwcroute problem 

Geert, Tom Vo says he will reproduce the fat srf wires problem for me tonight; so you 
probably don't need to duplicate it also. - Kurt 


From: vo (Tom Vo) 

To: wampler@merope.microunity.com (Kurt Wampler) 
Date: Wed, 15 Mar 95 9:57:45 PST 
Cc : torn (Tom Laidig) 

Kurt Wampler wrote .... 
> 

>Good morning, 
> 

>I have been trying to reproduce the srf /hwcroute interaction problem 
>you described yesterday, but to no avail. Basically, what I did was: 
> 

> 1) Place the cells in a gardswart . 

> 2) Load two thinwire nets from a ".srf" file with RLOAD. 

> 3) Ran hwcroute to route two fatwires (one of which failed to route) . 
> 

>The thinwires did not become bloated during this process. The df f 1 s 
>wire width table was left in the proper state, even with the failure of 
>one of the fatwires. 
> 

>What else do I need to add to this scenario to reproduce the problem 

>you were seeing? 

> 

>- Kurt 


Geert & I saw this problem on seperate builds (his euterpe , my mnemo) 

We did the same thing you're doing . I'll have to rebuild mnemo with that same recipe and 
save the files for your inspection . 
I'll do that later tonight . 


tvo 
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From: woody (Jay Tomlinson) 

Sent: Wednesday, March 15, 1995 3:32 PM 

To: 'lisar 1 

Cc: 'tor'; 'doi' 

Subject: euterpe_wrap 

In the checked in version of euterpewrap hermes interfaces are logged as: 

Sfstrobe (mninlog, "%b %x\n", clkinO, dinO); 
Sfstrobe (mnoutlog, "%b %x\n", clkoutO, doutO); 

This needs file format needs to be munged to run through mnparse.pl. I would 
like to change the fstrobe commands to: 

Sfstrobe (mninlog, "%x'\ dinO); 

$fstrobe (mnoutlog, "%x", doutO); 

This still needs to be modified because mnparse doesn't handle x's in 
early on, iorate/hc put out '00' for 2 cycles (I suspect this is due to 
CHEATRESET). But this modification is just stripping off the 1 st 30 or so 
lines. 

Is there some reason that the above format was chosen? Is there a different 
tool that takes this other format? Is this the '-s' option (.sen format) to 
mnparse.pl? 

woody 
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Subject: 


From: 


Sent: 

To: 

Cc: 


doi (Derek Iverson) 

Wednesday, March 15, 1995 3:32 PM 

'guarino'; 'gmo'; 'sandeep'; 'jeffm'; "gregg" 

'hestia' 

Software Bringup Meeting Minutes - March 15, 1995 


Software Bringup Meeting 


March 15, 1995 


Next Meeting: 


March 22 at 10:00 am. 


Attendees: guarino, gmo, sandeep, jeffm, doi, gregg 


New Action Items 


Item: Presentations on boot, gdb support, ukernel, 
Who : sandeep 
Status : New. 


Review of Action Items 


Item: Build tests that access and run in a bunch of memory spaces and 
states . 
Who : doi 


03/08 The test currently runs out of ibuffer but accesses data out 
of dbuf, dram, and hermes devices. The support to build 
the tests that specify hermes data regions in in progress (mkimg) . 

03/18 Support for hermes (including interleave) have been added. Still 
working on support for execution out of different regions. 


Item: Can a single cylinder (in an exception "loop*} lock out other 

cylinders? 

Who: jeffm 

Status: Pending. 

03/08 Jeff needs to talk with mws . 
03/18 No progress. 


Item: Terp needs to model "guaranteed forward progress for cache miss' 

in the same fashion as the hardware does. 
Who: lisa 

Status: In progress. 

03/01 Lisa has contacted raws and is implementing the same scheme 

used by the hardware . 
03/08 Still in progress. 
03/15 Progress continues. 


Item: Tests need to be written to verify performance issues 
Who: lisar, claseman 
Status: In progress. 


Status : 


In progress. 
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02/22 We need to flag performance problems as errors. 

Tests could be identified (and perhaps written) to measure 
and verify performance of the hardware for things like cache 
misses, tlb initialization, exceptions, etc. 

03/01 Lisar has started writing these tests. 

03/08 Work continues. 

03/15 Tim Claseman is assisting. 


Item: Determine what additional terp features are required 

(formally ^Status of Euterpe/Mnemo simulation') 
Who: gmo, jeffm 
Status : Pending . 

02/08 Jeffm figured that in 2 - 3 weeks time there would be a need 

for terp/mnemo capability to support the verification effort. 

An issue was raised that this may not be enought time for the 

required additions to terp to be made. 
02/15 Gmo is to create a list of requested features for terp and 

then he and jeffm (and others?) are to review the list and 

determine what will be implemented by terp. 
02/22 Gmo is ready to circulate the list. 
03/01 Nothing new. 

03/08 Gmo has shown a group of people the list but will post it. 
03/15 Still pending. 


Item: Test interleaved access 
Who: guarino, lisar 
Status: Pending. 

02/08 Loretta started to look at this but requires terp support. 

Terp changes are on hold until the real-time benchmark is 

is running again. 
02/2 2 Test has been written (interleave) but has not been run on 

hwterp yet. Lisar is going to run this on the hardware simulator. 
03/01 The test has been built, but not run yet. Derek is to check 

to be sure the hermes channels are enabled. 
03/08 Ready to run on HW. 

03/15 The tests generated by "stgen' are also capable of testing 
interleaved accesses. 


Item: Build microkernel tests for IKOS 
Who : doi , sandeep 
Status: In progress. 

02/08 Create images for boot test, snapshot images for microkernel 
tests . 

02/15 doi is still working on modifying the makefiles to build 
the _1 and 2 versions of this. 

iimura is creating a tool that modifies the ELF headers to 
have the proper real addresses (not just virtual) and gmo has 
modified mkimg to be able to understand the new headers. 

02/22 lisar says there are still problems building this. 

iimura is generating a code segment that will run in both 
rom and cerbrom that will proberly initialize dram 
and then branch to the test (which is in dram) . 

03/01 Sandeep is going to add code to boot so it can figure out 
if the cerb node is zero or eight. 

Derek is to start building the kernel tests so they may be 
loaded and run on the hw simulators. 
03/08 Ready to be built for hardware. 

03/15 Changes were made to libc and the microkernel (end-of-test 
support) . 

Sandeep has also created a dummy_boot that will allow us to 
preload the microkernel to speed up simulation times. These 
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changes should be available today. 


Suspended Items 


Item: Unsnap code 
Who: sandeep, guarino 
Status: Suspended. 

02/15 The issue of restarting the hardware from an IKOS dump 

was discussed and the need for an architectural snap /unsnap 
facility was questioned. 

Since the meeting it has been re-discovered (jeffm wasn't there 
to remind us of an earlier decision) that we are planning on 
loading architectural state into an IKOS simulation and not 
from a total IKOS logic dump. 

We also determined that when it came time to run some 
of the larger tests (real-time benchmark) we would need 
the capability to start an IKOS simulation from an 
architectural dump anyhow. 
03/01 For the short term we are going to focus on a simpler 
approach for loading and running DVTs, the kernel, and 
kernel tests. This item will likely come back in April. 


Item: Refine remote debugging environment 

Who : sandeep 

Status : Suspended 

02/08 We have to decide how control (and state) is to be returned 

to the debug stub after a test runs. 
02/15 Sandeep is not going to have time to start on this for a while. 


Item: Create performance test plan 
Who: jeffm, guarino 

Status: [11/30] No progress as focus is on functionality. 

We continue to run tests to help us compare terp vs hardware 
performance . 

We still need to put together the actual performance tests that 
need to be run on the hardware. 


Completed Items 


Item: Determine what is initialized (and how) in terp 

Who : gmo 

Status : Done . 

0308 Gmo took this item. 


Item: Running Real-time Benchmark on Euterpe/ Calliope HW Simulator 

(combined with previous "Run real-time test on the HW simulator) 
Who: gregg, lisar 

Status: Removed. This has moved beyond the event horizon that we want 

to track in the software bringup meeting at this time. There 
is a seperate "benchmark' meeting that tracks detailed progress. 

02/08 There are problems getting the benchmark to run on the 
software simulator. Work continues to find out where 
the problems are. The compilers, simulator, kernel, and 
benchmark areas are "frozen 1 (in terms of checking in 
new changes) until the problem has been identified. 
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02/15 It is estimated that by the middle of March we should have 
cycles available on the IKOS and a IKOS compatible calliope 
that can be run with the real-time benchmark, 
Lisar will be the verification resource to help with running 
this application. 

The benchmark is working and now the effort is focused on 
getting it to fit in the real-time and memory budgets. 
03/01 The TV application has bogged down recently but work 
continues . 

It is believed that this won't be ready to run (from the software 
hand the hardware perspective) until April. 
03/08 lisar has starting building a IKOS compatible calliope. 

The benchmark team is looking at a way to build a reduced 
subset of the test. 


Item: DVT boot 
Who : sandeep 
Status : Done . 

02/08 First step is to get nano-boot running on the HW simulator. 
02/15 Sandeep has completed the boot code and now we need to 

build a dvt that can be loaded by the DVT boot (i.e. it 

is loaded into the top 8K of D and I buffer) . 

Jeffm commented that for most DVTs, they must be loaded at 

the beginning of D and I buffer and the beginning of ram. 

We will have to come up with an alternative for loading DVTs. 

Sandeep noted that dvts will not be started in event mode 

which is in contrast to jeffm' s mail about the initial state 

for dvts (but we knew this already) . 
02/22 We want to understand if we can modify the DVTs so they do not 

require that they are loaded at the beginning of D&Ibuf and ram. 
03/01 Sandeep is going to implement a DVT boot mechanism. 
03/08 Almost done. Testing and final check- in of changes soon. 


Test Status and General Discussion 


Jeff talked about current HW and test status. 

The "unix» test is causing the machine to reset on the hw simulator. 

The dram controller occasionaly gives the wrong quadlet and this has prevented a number of 
tests from running successfully. 

There is a bug in the snake bus that causes X propogation during icache handling. 
Gmo is running "_1 1 tests on terp and getting the print output. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, March 15, 1995 4:38 PM 

'fwo (Fred Obermeier)' 

'billz'; 'fwo'; 'geert'; 'hopper"; 'ong'; 'torn' 

Re: PCOMP fails, why? 


Fred Obermeier wrote (on Wed Mar 15) : 

Yes, I have initiated pin name changes to help fix a lot of csyn errors 
on euterpe. However, I also have not been able to get a build of 
f wo_euterpe-passl . spivs in bsrc since then. There seems to be some 
Makefile problem. It's always been something over the last few days. 

The verilog models got updated on March 10th. See files in 
/u/chip/proteus/verilog/elib/eamem*v. I sent Tim some email after 
that happened requesting that he include these updated verilog files 
into to the snapshot. Maybe the timing files need to be included with 
the snapshot too, if they are done. 

The snapshot should be fully up to date at this point, so if it still fails to compile for 
let me know and I'll investigate. 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, March 15, 1995 7:54 PM 

To: 'billz'; 'dickson'; 'raws'; 'tbr'; 'woody' 

Cc: 'jeffm' 

Subject: euterpe simulation 

I have attempted to add support for multiple dram configuations to the verilog 
simulation environment. This is because the _1 tests set the euterpe to use 
dram configuration 1 where as the 0 use configuration 0. 

You will need to pick up a new Makefile and a new dr/dr.config.h and a euterpe_wrap. V. 
Let me know if you have any problems. 

Lisa R. 
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From: fwo (Fred Obermeier) 

Sent: Wednesday, March 15, 1995 9:08 PM 

To: 'hardheads' 

Cc: 'fwo' 

Subject: Csyn Euterpe BOM 247 errors 


Hi, 

The csyn run of fwo_euterpe-passl . spivs generated from bsrc BOM 247.0 indicates the 
following problems. Please take a look at the errors and let me know if this is ok or 
not. Of the 119 ExclusivelnputSwingCheck errors given, I've truncated this down to a 
shortened uniquified list by replacing numeric differences by # where # can be any number 
of digits. To examine the full list of errors, please look at 

/u/f wo/chip. bsrc/euterpe/verilog/bsrc/SAVE. 24 7 /mothra4 /new. csyn 

Fred. 


error (ExclusivelnputSwingCheck. 102 ) in file "fwo_euterpe-passl . spivs" 
Reason: One driver needs to be half -swing 


exclusive inputs 

instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


drivers 



instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


exclusive topmost 

instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


instance 

path 


cellname 

path 


instance 

path 


cellname 

path- 


instance 

path 


cellname 

path 



top . xif euincgopgcrryilluO 

top . xbmux5df 4 s 

top . xif euincgopgcrryilluO 

t op . xbmuxS d f 4 s 

top . xif euincgopgcrryilluO 

top . xbmux5df 4 s 

top . xif euincgopgcrryilluO 

t op . xbmux5 df 4 s 

top .xif euincgopgcrryilluO 

t op . xbmux5 df 4 s 


if e_if epgszsel_4 

sel_a0peh_4 

ife_if epgszsel_3 

sel_a0peh_3 

ife_if epgszsel_2 

sel_a0peh_2 

if e_if epgszsel_l 

sel_aOpeh_l 

if eif epgszsel _o 

sel_aOpeh_0 


top . xif euif epgszselu4 , 
top . xbcmos2ecldf 2s 
top .xif euif epgszselu3 . 
top.xbcmos2ecldf 2s 
top . xif euif epgszselu2 . 
top ,xbcmos2ecldf 2s 
top .xif euif epgszselul . 
top . xbcmos2ecldf 2s 
top .xif euif epgszseluO . 
top . xbcmos2ecldf 2s 
nets 

top . if e_if epgszsel_4 
top. if e_if epgszsel_4 
top . if e_if epgszsel_3 
top . if e_if epgszsel_3 
top . if e_if epgszsel_2 
top . if e_if epgszsel_2 
top . if e_if epgszsel_l 
top . if e_if epgszsel_l 
top . if e_if epgszsel_0 
top . if e_if epgszsel_0 

Reason: Two e inputs. Use dif f . instead 
exclusive inputs 

instance path: 

cellname path: 

instance path: 

cellname path: 
drivers 

instance path: 

cellname path: 


if e_if epgszsel_4 
q_ad0pf 

ife_ifepgszsel_3 
q_ad0pf 

if e_ifepgszsel_2 
q_ad0pf 

if e_if epgszsel_l 
q_ad0pf 

if e_if epgszsel_0 
q_adOpf 


top . xccu3 8u# . cc_loadd 
top .xbmuxf f 2df #s . sel_aOpeh_l 
top . xccu3 8u# . cc_loadc_n 
top . xbmuxf f 2df #s . sel_a0peh_0 

top . xccu3 OuO . cc_loadd 
top . xbf f dh6s . q_adOph 
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instance path: 
cellname path: 
exclusive topmost 
instance path: 
cellname path: 
instance path: 
cellname path: 


top . xccu2 9u0 . cc_loadc_n 
top . xbf f bdh8 s . q_andOph 
nets 

top . cc_loadd 
top . cc_loadd 
top . cc_loadc_n 
top . cc_loadc_n 


Use dif f . instead 


.xll4p_l.xl6p_l 


Reason: Two e inputs 
exclusive inputs 

instance path: top . xcr . x88p_l .x2p_l 
. sel_alpeh_l 

cellname path: top.cr .cr3a . crarray . crrdec 
. craddraplsO . craddmpl . sel_alpeh_l 

instance path: top . xcr . x88p_l . x2p_l . xll4p_l . xl6p_l 
. sel_alpeh_0 

cellname path: top.cr . cr3a . crarray . crrdec 
. craddmplsO . craddmpl . sel_alpeh_0 
drivers 

crrdec . xl2p_l . sel_alpeh_l 
crrdec . crasef . sel_alph 
crrdec . xl9p_l . sel_alpeh_0 
crrdec . crasef . sel_alph 
exclusive topmost nets 

instance path: top . xcr . x88p_l . x2p_l . xll4p__l . sel_alpeh_l 
cellname path: top.cr .cr3a . crarray . crrdec . sel_alpeh_l 
instance path: top .xcr .x88p_l .x2p_l . xll4p_l . sel_alpeh_0 
cellname path: top.cr . cr3a . crarray . crrdec . sel_alpeh_0 


x#xlp_l 


x#xlp_l 


instance path: 
cellname path: 
instance path: 
cellname path: 


Use diff. 


Reason: Two e inputs, 
exclusive inputs 
instance path: 
. sel_alpeh_l 

cellname path: 
. craddmplsO . craddmpl 
instance path: 
. sel_alpeh_0 

cellname path: 
. craddmplsO . craddmpl . sel_alpeh_0 
drivers 

instance path 
cellname path 
instance path 
cellname path: 


top .xcr . x88p 

top.cr .cr3a 
sel_alpeh_l 

top .xcr .x88p 

top.cr .cr3a 


instead 

_l.x2p_l .xll4p_l.xl6p_l 

. crarray . crrdec 
_l.x2p_l .xll4p_l.xl6p_l 

. crarray . crrdec 


• xlp_l 


• xlp_l 


crrdec .xl2p_l 
crrdec . crasef 
crrdec .xl9p_l 
crrdec . crasef 


exclusive topmost nets 


. sel_alpeh_l 
. sel_alph 
. sel_alpeh_0 
. sel_alph 


instance path 
cellname path 
instance path 
cellname path 


top . xcr . x8 8p_: 
top.cr . cr3a 
top. xcr .x88p_: 
top.cr . cr3a 


1 . x2p_l . xll4p_l . sel_alpeh_l 
. crarray . crrdec . sel_alpeh_l 
1 . x2p_l . xll4p_l . sel_alpeh_0 
crarray . crrdec . selalpehQ 


Reason: Two e inputs 
exclusive inputs 

instance path: 

cellname path: 

instance path: 

cellname path: 
drivers 

instance path: 

cellname path: 

instance path: 

cellname path: 
exclusive topmost nets 


Use diff. instead 

top .xmstu0#u00u23u# .mst_uOO_u00_bsel_l 
top . xbmuxf f 2df #s . sel_aOpeh_l 
top.xmstu0#u0 0u23u# . mst_uOO_u00_bsel_0 
top .xbmuxf f 2df #s . sel_a0peh_0 

top . xmstu0 0u0 0u07ul . mst_uOO_u00_bsel_l 
top . xbf f dh6 s . q_adOph 

top.xmstu0 0u00u07u0 .mst_uOO_u0 0_bsel_0 
top.xbffdh6s .q_ad0ph 


instance path 
cellname path 
instance path 
cellname path 


top . mst_u0 0_u0 0_bsel_l 
top . mst_u0 0_u0 0_bsel_l 
top . mst_u0 0_u0 0_bsel_0 
top . mst_uO 0_u0 0_bsel_0 


Reason: Two e inputs. Use diff. instead 


Exhibit C12 


Page 279 of 643 


exclusive 
instance 
cellname 
instance 
cellname 

drivers 
instance 
cellname 
instance 
cellname 

exclusive 
instance 
cellname 
instance 
cellname 


inputs 

path: top .xmstu0#u00u23u# .mst_u02_u0 0_bsel_l 

path: top .xbmuxf f 2df #s . sel_aOpeh_l 

path: top .xmstu0#u00u23u# . mst_u02_u00_bsel_0 

path: top .xbmuxf f 2 df #s . sel__aOpeh_0 

path: top.xmstu02u0 0u07ul .mst_u02_u00_bsel_l 

path: top.xbffdh6s . q_adOph 

path: top .xmstu02u0 0u07u0 . mst_u02_u0 0__bsel_0 

path: top.xbffdhes . q_adOph 

topmost nets 

path: top.mst_u02_u00_bsel_l 

path: top .mst_u02_u0 0_bsel_l 

path: top .mst_u02_u00_bsel_0 

path: top .mst_u02_u00__bsel_0 


Reason: Two e inputs 
exclusive inputs 
instance path: 
cellname path: 
instance path: 
cellname path: 
drivers 

instance path: 
cellname path: 
instance path: 
cellname path: 


Use diff. instead 

top . xnbdbuf dout# . nb_dbuf _xselaO_ablpeh_l 
top . eam2f f dhl6sllx2a . sel_alpeh_l 
top . xnbdbuf dout# . nb_dbuf _xselaO_ablpeh_0 
top.eam2f fdhl6sllx2a . sel__alpeh_0 


top . xnbdbuf rselbuf 1 . nb_dbuf _xselaO_ablpeh_l 
top.ealplqh3s4x2a . qjblph 

top . xnbdbuf rselbuf 0 . nb_dbuf _xselaO_ablpeh_0 
top . ealplqh3 s4x2a . q_blph 
exclusive topmost nets 

instance path: top . nb_dbuf _xselaO_ablpeh_l 
cellname path: top . nb_dbuf _xselaO_ablpeh_l 
instance path: top . rib_dbuf __xselaO_ablpeh_0 
cellname path: top . nb_dbuf _xselaO_ablpeh_0 


Exhibit C12 


Page 280 of 643 


From: geert (Geert Rosseel) 

Sent: Wednesday, March 1 5, 1995 9:39 PM 

To: Vanthof 

Cc: 'lisar 1 ; 'tbr'; 'vo' 

Subject: Euterpe ready for DRC/SHORTS/LVS 


Hi, 

I build a euterpe in the snapshot for LVS and DRC. The snapshot is 
in /n/auspex/s4 1/euterpe-snapshot/euterpe. 

Thsi euterpe was build from the top directory (gmake euterpe), so 
that path should be pretty much working now. 

This version contains all custom blocks and ck. As soon as Dave 
had grabbed the necessary files for DRC and LVS, I'd like to 
build a euterpe with everything in it. 

Geert 
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From: mws (Mark Semmelmeyer) 

Sent: Wednesday, March 15, 1995 9:41 PM 

To: 'two'; 'tbr* 

Cc: 'hardheads' 

Subject: Re: Csyn Euterpe BOM 247 errors 


> From fwo Wed Mar 15 18:08:27 1995 

> error { Exclusive Input SwingCheck. 102) in file "fwo_euterpe-passl . spivs" : 
> 

> Reason: One driver needs to be half -swing 

> exclusive inputs 

> instance path: top , xif euincgopgcrryilluO . if e_if epgszsel_4 

> cellname path: top .xbmuxSdf 4s . sela0peh_4 

> drivers 

> instance path: top .xif euif epgszselu4 . if e_if epgszsel_4 

> cellname path: top . xbcmos2ecldf 2s .q_ad0pf 

> exclusive topmost nets 

> instance path: top . if e_if epgszsel_4 

> cellname path: top . if e_if epgszsel_4 

I never noticed before that we don't have half swing cmos2ecl converters. That is the 
cause of the above problem. I can add a buffer on 1 of the 5 bits. Of course, I have 
this old note asking whether there should be a synchonizer here anyway. . . 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, March 15, 1995 10:01 PM 

'mws (Mark Semmelmeyer)' 

'fwo'; 'geeif 

Re: Csyn Euterpe BOM 247 errors 


Mark Semmelmeyer wrote (on Wed Mar 15) : 


> From fwo Wed Mar 15 18:08:27 1995 


> error (ExclusivelnputSwingCheck . 102) in file 


" f wo_euterpe-passl . spivs " : 


> Reason: One driver needs to be half- swing 

> exclusive inputs 

> instance path: top . xif euincgopgcrryilluO , if e_if epgszsel__4 

> cellname path: top .xbmux5df 4s . sel_a0peh_4 

> drivers 

> instance path: top . xif euif epgszselu4 . if e_if epgszsel_4 

> cellname path: top.xbcmos2ecldf 2s . q^adOpf 

> exclusive topmost nets 

> instance path: top . if e_if epgszsel_4 

> cellname path: top . if e_if epgszsel_4 


I never noticed before that we don't have half swing cmos2ecl 
converters. That is the cause of the above problem. I can 
add a buffer on 1 of the 5 bits. Of course/ I have this old 
note asking whether there should be a synchonizer here anyway. . . 

Since cmos to ECL converters only handle "DC" signals there is no power/performance 
advantage from having the half swing version. 

Seems a shame to have to stuff a buffer in here. I have to admit I'm struggling to 
remember the reason for the "one must be half swing" 
rule here again. 


Tim 
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From: mws (Mark Semmelmeyer) 

Sent: Wednesday, March 15, 1995 10:09 PM 

To: 'mws'; 'tor' 

Cc: 'fwo'; 'geert' 

Subject: Re: Csyn Euterpe BOM 247 errors 


> From tbr Wed Mar 15 19:01:04 1995 
> 

> Mark Semmelmeyer wrote (on Wed Mar 15) : 
> 

> 

> > From fwo Wed Mar 15 18:08:27 1995 
> 

> > error ( Exclusive Input SwingChe ck . 102) in file 
11 f wo_euterpe-passl . spivs " : 

> > 

> > Reason: One driver needs to be half -swing 

> > exclusive inputs 

> > instance path: top . xif euincgopgcrryilluO . if e_if epgszsel_4 

> > cellname path: top .xbmuxSdf 4s . sel_a0peh_4 

> > drivers 

> > instance path: top . xif euif epgszselu4 . if e_if epgszsel_4 

> > cellname path: top ,xbcmos2ecldf 2s . q_ad0pf 

> > exclusive topmost nets 

> > instance path: top . if e_if epgszsel _4 

> > cellname path: top . if e_if epgszsel_4 
> 

> I never noticed before that we don't have half swing cmos2ecl 

> converters. That is the cause of the above problem. I can 

> add a buffer on 1 of the 5 bits. Of course, I have this old 

> note asking whether there should be a synchonizer here anyway. . . 
> 

> Since cmos to ECL converters only handle "DC" signals there is no 

> power/performance advantage from having the half swing version. 
> 

> Seems a shame to have to stuff a buffer in here. I have to admit I'm 

> struggling to remember the reason for the "one must be half swing" 

> rule here again. 
> 

> Tim 

Wasn't something about lower bipolar saturation if there was skew in the select switching 
such that all selects could look low (very low if full swing) for a short period? 

My other question was on the synchronizer. Since we have become more conservative on 
synchronization, I wonder if changing page size without one could be too tricky. 
Maybe another way out would be to only enable IFe page boundry crossing checks if memory 
management is off (then we could say don't change page size with it on) . 

If I have any cases where I was depending on a max page size to trigger hiccups to update 
if etch pointers etc. (can't remember any at the moment although br prediction is ripe for 
such stuff), I could add that as a fixed separate case. 
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From: tbr (Tim B. Robinson) 

Sent: Wednesday, March 15, 1995 10:13 PM 

To: 'mws (Mark Semmelmeyer)' 

Subject: Re: Csyn Euterpe BOM 247 errors 


Mark Semmelmeyer wrote (on Wed Mar 15) : 

Wasn't something about lower bipolar saturation if there 
was skew in the select switching such that all selects 
could look low (very low if full swing) for a short 
period? 

Probably. Seems moot in this case at least. 

My other question was on the synchronizer. Since we have 
become more conservative on synchronization, I wonder if 
changing page size without one could be too tricky. 
Maybe another way out would be to only enable IFe page 
boundry crossing checks if memory management is off 
(then we could say don't change page size with it on) . 
If I have any cases where I was depending on a max page 
size to trigger hiccups to update if etch pointers etc. (can't 
remember any at the moment although br prediction is ripe 
for such stuff), I could add that as a fixed separate case. 


I don't have the document to hand. Where is the Cerberus field that controls this? If 
it's in octlet 6 it may be a problem since it would take immediate effect. If it's in a 
deferred octlet, we could demand a reset to change it. 


Tim 
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From: torn (Tom Laidig (tau)) 

Sent: Wednesday, March 15, 1995 10:51 PM 

To: 'Mark Semmelmeyer' 

Cc: 'tbr (Tim B. Robinson)'; 'two (Fred Obermeier)'; 'hardheads'; 'tau' 

Subject: Re: Csyn Euterpe BOM 247 errors 


Mark Semmelmeyer writes : 

> From fwo Wed Mar 15 18:08:27 1995 

> error (ExclusivelnputSwingCheck. 102) in file " f wo_euterpe-passl . spivs" : 
> 

> Reason: One driver needs to be half- swing 

> exclusive inputs 

> instance path: top .xif euincgopgcrryilluO . ife_if epgszsel_4 

> cellname path: top . xbmux5df 4s . sel_a0peh__4 

> drivers 

> instance path: top .xif euif epgszselu4 . if e_ifepgszsel_4 

> cellname path: top .xbcmos2ecldf 2s . q_ad0pf 

> exclusive topmost nets 

> instance path: top . if e_if epgszsel_4 

> cellname path: top . if e_if epgszsel_4 

I never noticed before that we don't have half swing cmos2ecl 
converters. That is the cause of the above problem. I can add a 
buffer on 1 of the 5 bits. Of course, I have this old note asking 
whether there should be a synchonizer here anyway. . . 

I think the rationale for having no half -swing cmos2ecl converters was that the only 
advantage of half -swing signals was their speed -- an irrelevant concern for signals 
coming from cmos . 

Speaking of which. . . I guess I missed the reasoning for why (if I understand the error 
message) one of the exclusive inputs must come from a half- swing driver. 


\_ 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, March 15, 1995 11:10 PM 

'mws (Mark Semmelmeyer)' 

'mws' 

Re: Csyn Euterpe BOM 247 errors 


Mark 


Semmelmeyer wrote (on Wed Mar 15) : 


> 


> 


From tbr Wed Mar 15 19:48:45 1995 

Mark Semmelmeyer wrote (on Wed Mar 15) : 


> 


> 


IPe page size is in octlet 6. 


> 


> So, is there a safe sequence that guarantees we can set this at 

> initialization time independent of synchronization? 

I thinks this will work: 

Reset memory management off which IFe detects using the synchronized 
copy. Use that copy (not depending on Cerberus) to some forced page 
size (64 would make diagnostics happy by causing the existing high 
number of BHicMid's to continue) . 

Software writes if etch page size to octlet 6. No effect since 
IFe is still forcing, but allows cmos lines to settle. 
Software write memory management on to octlet 6 . Sometime 
later this will cleanly switch from the forced page size 
to the settled page size. 

Software must not change both memory management and if etch 
page size in same write. I presume no extra delay is needed 
between the writes as the hardware delays between the two 
should be enough for cmos to settle. 

it would be easy to put some extra delay in the memory mgmt enable (say a couple of 
Cerberus clocks) to ensure te other lines are stable, then there would be no problem with 
a single write. 

Also the page size was fully decoded in cerberus to save 
eel atoms, but this costs 5 tracks through the choke point. 
We should encode to 3 wires and pay a few atoms in eel. 

Worth knowing if we are desparate . 


Tim 
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From: 
Sent: 
To: 


Subject: 


Curtis Abbott [abbott@microunity.com] 
Wednesday, March 15, 1995 11:13 PM 

Craig Hansen; 'gap@microunity.com 1 ; 'gmo@microu nity.com'; 'guarino@microunity.com'; 
'hayes@microunity.com'; John Moussouris; 'tbr@microunity.com'; 'tony@microunity.com' 
notes on today's meeting 


Following today's software strategy meeting, I volunteered to write up and distribute what 
I think we decided. I won't try to recapitulate the entire meeting, just the conclusions 
and the inconclusive parts. 
Here goes . . . 

First, I believe there was considerable clarification of various company goals. In 
general, we decided 

(1) it is important to continue work on Hestia, but to cast it as a technology demo, not a 
product; 

(2) it is possible to considerably simplify the software required for the earnback; 

(3) there is a way to think of Pandora as (almost completely) a modular package for our 
chips, as a channel to partnered and non-partnered customers, thereby mostly decoupling it 
from the earnback. 

The emerging picture, then, is that we currently have 3 ongoing activities/goals, with one 
or more further activities/goals expected to emerge this year as a result of upfront 
customer commitments. One of the possibilities here is a cable modem, which we spent some 
time discussing and heard some breaking news about, but took no decisions on. 

Thus, we were led to identify 3 questions: 

1. What software is needed to achieve the earnback? 

2 . What software is needed to finish Hestia as a technology demo? 

3. What software is needed to help sell Pandora -the -modular -package? 

We spent some time interpreting the requirements for the earnback; we were in a "ruthless 
pruning" frame of mind. We decided it might be sufficient to sell production units of 
Euterpe (and Cronus) bricks, without even Mnemosyne. To run SPEC for the measurements, we 
could use our current 0SF port, the /dev/host interface (which uses 

Cerberus) for i/o, and 16MB of memory. We would not necessarily ship Unix by 12/31/95. 
In that case, we would presumably ship a cross development environment so our customer (s) 
could do something with their bricks. 

[Since the meeting, I've gone over Lois' summary of the contract with her. It's true that 
the language is remarkably unrestrictive in some ways. The key issues, I believe, will be 

(1) whether a brick is a workstation (no snickers, please) ; (2) whether the first spin of 
both Euterpe and Cronus will be robust and reliable enough to qualify as production units. 
The reliability issue appears to be mitigated by the fact that the contract essentially 
guarantees that any disputes as to the earnback are resolved in less than 6 months . The 
robustness issue is quite real, and sharpens the importance of making a good call on 
tapeout versus verification.] 

We spent very little time talking about the second question - - I believe this is something 
the software managers should resolve internally and report within 10 days. 

Our discussions of the third question were inconclusive. We identified 2 (related) end- 
user application areas for Pandora (SW development and combined SW/HW development) , and 4 
OEM application areas (video conferencing, video encoding, audio/video effects, 
internetworking) . Of these, we felt that 1/2 or more could benefit from Unix, but some 
(video conferencing in particular) probably prefer something more like the microkernel. 
We discussed ways of using the other 4 threads with a single -threaded Unix port -- such an 
extension would be required, and a number of design ideas have been mooted. 

Another part of this discussion was about shipping a cross development environment soon. 
This requires work on documentation, test, productizing in general, and perhaps some kind 
of DSP library. Also, having customers means supporting them, whether it's before or 
after hardware is available. 

I suggest that the software managers, along with Tony, try to come up with a plan in this 
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area that we can present at a future meeting. 


Actions: 

- Tbr to verify we can put 16MB of SDRAM on a Euterpe brick. 

- Gmo to verify we can run SPEC in 16MB (or alternatively, in 8MB, in which case Tbr is 
off the hook) . 

- software managers to clarify and write up Hestia tech demo goals. 

- Tony and software managers develop and present plan on the Pandora software requirements 
questions . 
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From: tbr 

Sent: Thursday, March 16, 1995 12:02 AM 

To: 'Curtis Abbott' 

Cc: Craig Hansen; 'gap@microunity.com'; 'gmo@microunity.com'; 'guarino@microunity.com'; 

'hayes@microunity.com'; John Moussouris; 'tony@microunity.com' 

Subject: notes on today's meeting 

Follow Up Flag: Follow up 

Flag Status: Red 


Curtis Abbott wrote (on Thu Mar 16): 
Actions: 

- Tbr to verify we can put 16MB of SDRAM on a Euterpe brick. 

Not with the current PCB design. It should be an easy change to 
make a version with 8 4Mx4 parts. I need to check we have enough 
space inthe module for the extra chips. 

Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


Tim B. Robinson [tbr@gaea.microunity.com] 
Thursday, March 16, 1995 12:02 AM 
'Curtis Abbott' 

Craig Hansen; 'gap@microunity.com'; 'gmo@microu nity.com'; 'guarino@microunity.com'; 
'hayes@microunity.com'; John Moussouris; 'tony@microunity.com' 
notes on today's meeting 


Curtis Abbott wrote (on Thu Mar 16} : 
Actions : 

- Tbr to verify we can put 16MB of SDRAM on a Euterpe brick. 

Not with the current PCB design. It should be an easy change to make a version with 8 
4Mx4 parts. I need to check we have enough space inthe module for the extra chips. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Thursday, March 16, 1995 12:08 AM 

'woody'; 'tbe'; 'dbulfer'; 'pmayer' 

'pandora' 

Euterpe module 


A potential requirement for 16MB of SDRAM in the Euterpe brick has come up. 

This can be acheived using 8 4Mx4 parts which Euterpe supports, but the current PCB design 
does not. It may not be practical to have a single PCB layout support 2 1Mx16, 4 2Mx8, or 
8 4Mx4 parts, but clearly we could have two different PCBs in that case. The most 
important thing is to be sure we have physical space to accommodate 8 SDRAM components and 
that we can cool them in the module . 

Tom, pattie, can you look at these issues to make sure the current form factor can 
accommodate this option if it shoud become a hard requirement? The 4Mx4 part is in the 
same package as the 2Mx8 . 


Tim 
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From: wingard (Drew Wingard) 

Sent: Thursday, March 16, 1995 12:57 AM 

To: 'tau' 

Cc: 'hardheads' 

Subject: Re: Csyn Euterpe BOM 247 errors 


Tom Laidig writes : 

Mark Semmelmeyer writes : 

> From fwo Wed Mar 15 18:08:27 1995 

> error (ExclusivelnputSwingCheck . 102 ) in file 
"f wo_euterpe-passl . spivs" : 

> 

> Reason: One driver needs to be half -swing 

> exclusive inputs 

> instance path: top.xif euincgopgcrryilluO . if e_if epgszsel_4 

> cellname path: top . xbmuxSdf 4 s , sel_a0peh_4 

> drivers 

> instance path: top . xif euif epgszselu4 . if e_if epgszsel_4 

> cellname path: top . xbcmos2ecldf 2s . q_ad0pf 

> exclusive topmost nets 

> instance path: top . if e_if epgszsel_4 

> cellname path: top . if e_if epgszsel_4 

I never noticed before that we don't have half swing cmos2ecl 
converters. That is the cause of the above problem. I can add a 
buffer on 1 of the 5 bits. Of course, I have this old note asking 
whether there should be a synchonizer here anyway. . . 
> 

> I think the rationale for having no half- swing cmos2ecl converters was 

> that the only advantage of half -swing signals was their speed --an 

> irrelevant concern for signals coming from cmos . 

> Speaking of which. . . I guess I missed the reasoning for why (if I 

> understand the error message) one of the exclusive inputs must come 

> from a half -swing driver. 

The reasoning behind the half- swing requirement is simply that we have no way to guarantee 
that at least one of an "exclusive" set of bits is actually high. If a logical "don't 
care" case temporarily left all (full -swing) inputs low, we could run into electrical 
problems (such as saturating the bottom switch in a muxen gate) that would delay the 
gate's response once a select input rose again. A half -swing signal solves the problem by 
raising the "least positive voltage" to that of a vref (which is always assumed to be a 
"safe" input level) . 

In other words, we're confident that we don't have a *logic* problem. We should be 
correctly modeling all select inputs low as an indeterminate 

(X) output. The worry is that our timing models do not consider the transition delay 
between this state and a "normal" driven output. 

Drew 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Thursday, March 16, 1995 1:19 AM 
'Geert Rosseel' 

'lisar (Lisa Robinson)'; 'tbr (Tim B. Robinson)'; Vo (Tom Vo)'; Vanthof (Dave Van't Hof)'; 

'hopper (Mark Hofmann)' 

Re: Euterpe ready for DRC/SHORTS/LVS 


Geert Rosseel writes: 
> 

> Hi, 


> I build a euterpe in the snapshot for LVS and DRC. The snapshot is in 

> /n/auspex/s41/euterpe- snapshot /euterpe . 
> 

> Thsi euterpe was build from the top directory (graake euterpe) , so that 

> path should be pretty much working now. 
> 

> This version contains all custom blocks and ck. As soon as Dave had 

> grabbed the necessary files for DRC and LVS, I'd like to build a 

> euterpe with everything in it . 
> 

> Geert 


I have started the lvs and a lower layer drc run. The upper drc is queued up to start 
after one of the mnemo jobs finishes. However, I don't normally 'save' the layouts, but 
will do so in this case. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim .h> Don't blame 
me, I didn't vote for him! 


Dave 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Thursday, March 16, 1995 1:33 AM 
'wingard (Drew Wingard)' 
'hardheads'; 'tail' 

Re: Csyn Euterpe BOM 247 errors 


Follow Up Flag: Follow up 
Flag Status: Red 

Drew Wingard wrote (on Wed Mar 15): 

The reasoning behind the half-swing requirement is simply that we have no 
way to guarantee that at least one of an "exclusive" set of bits is actually 
high. If a logical "don't care" case temporarily left all (full-swing) 
inputs low, we could run into electrical problems (such as saturating 
the bottom switch in a muxen gate) that would delay the gate's response once 
a select input rose again. A half-swing signal solves the problem by 
raising the "least positive voltage" to that of a vref (which is always 
assumed to be a "safe" input level). 

In other words, we're confident that we don't have a * logic* problem. We 
should be correctly modeling all select inputs low as an indeterminate 
(X) output. The worry is that our timing models do not consider the 
transition delay between this state and a "normal" driven output. 

The models should put out Z in this case (which will be treated as X 
by succeeding gates). It would appear from this description that the 
restriction really only applies to 3 level stack gates and that 
regular muxes (two level) should not really need to be restricted this 
way. Is that so? 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Thursday, March 16, 1995 1:33 AM 
'wingard (Drew Wingard)' 
'hardheads'; 'tau' 

Re: Csyn Euterpe BOM 247 errors 


Drew wingard wrote (on Wed Mar 15) : 

The reasoning behind the half -swing requirement is simply that we have no 
way to guarantee that at least one of an "exclusive" set of bits is actually 
high. If a logical "don't care" case temporarily left all (full -swing) 

inputs low, we could run into electrical problems (such as saturating 
the bottom switch in a muxen gate) that would delay the gate's response once 
a select input rose again. A half -swing signal solves the problem by 
raising the "least positive voltage" to that of a vref (which is always 
assumed to be a "safe" input level) . 

In other words, we're confident that we don't have a *logic* problem. 

We 

should be correctly modeling all select inputs low as an indeterminate 
(X) output. The worry is that our timing models do not consider the 
transition delay between this state and a "normal" driven output. 

The models should put out Z in this case (which will be treated as X by succeeding gates) . 
It would appear from this description that the restriction really only applies to 3 level 
stack gates and that regular muxes (two level) should not really need to be restricted 
this way. Is that so? 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wingard (Drew Wingard) 
Thursday, March 16, 1995 2:37 AM 
*tbr l 

'hardheads' 

Re: Csyn Euterpe BOM 247 errors 


Tbr wrote : 

> Drew Wingard wrote (on Wed. Mar 15) : 
> 

> The reasoning behind the half -swing requirement is simply that we 

> have 
no 

> way to guarantee that at least one of an "exclusive" set of bits is 
actually 

> high. If a logical "don't care" case temporarily left all 
(full -swing) 

> inputs low, we could run into electrical problems (such as saturating 

> the bottom switch in a rauxen gate) that would delay the gate's 
response once 

> a select input rose again. A half- swing signal solves the problem by 

> raising the "least positive voltage" to that of a vref (which is 
always 

> assumed to be a "safe" input level) . 
> 

> In other words, we're confident that we don't have a * logic* problem. 
We 

> should be correctly modeling all select inputs low as an indeterminate 

> (X) output. The worry is that our timing models do not consider the 

> transition delay between this state and a "normal" driven output. 
> 

> The models should put out Z in this case (which will be treated as X 

> by succeeding gates) . It would appear from this description that the 

> restriction really only applies to 3 level stack gates and that 

> regular muxes (two level) should not really need to be restricted this 

> way. Is that so? 

Well, sort of. 

Some of our multiplexer structures accept "mp" inputs at their top level and "np" at their 
second (or equivalently , "mp" on select inputs that get internally shifted down one Vbe) . 
These gates have a somewhat different 

vulnerability: if the bases of the select transistor are all "low" 2pf signals then the 
emitters of the select transistors are low enough that the NMOS "current sources" will 
have severely reduced output current at certain operating conditions. This would make 
both outputs tend to float high. 

We decided at the csyn/ eel It est meeting long ago that we were not prepared to invest the 
time required to verify that our timing numbers would be correct in cases like this. Even 
if the normal muxes work fine, we know that the muxens have a problem, and now we need a 
way to reliably differentiate between the two cases in csyn. 

We could accomplish this by changing the signal naming convention to make the behavior 
explicit (I can see the rotten fruit flying my way from the folks who would have to change 
a bunch of pin names, then time and verify the resulting cells) or ask for a new csyn 
feature to let us apply certain rules only to certain cells (more rotten fruit, this time 
from fwo) . 

I don't know for certain, but from fwo's list it looks like it might be simpler to buffer 
a signal or two than to add the new csyn/signame "feature" 
this late in the game. 


Drew 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Thursday, March 16, 1995 2:40 AM 
'wingard (Drew Wingard)' 
'hardheads' 

Re: Csyn Euterpe BOM 247 errors 


Follow Up Flag: Follow up 
Flag Status: Red 

Drew Wingard wrote (on Wed Mar 15): 
Tbr wrote: 

> Drew Wingard wrote (on Wed Mar 15): 

> 

> The reasoning behind the half-swing requirement is simply that we have no 

> way to guarantee that at least one of an "exclusive" set of bits is actually 

> high. If a logical "don't care" case temporarily left all (full-swing) 

> inputs low, we could run into electrical problems (such as saturating 

> the bottom switch in a muxen gate) that would delay the gate's response once 

> a select input rose again. A half-swing signal solves the problem by 

> raising the "least positive voltage" to that of a vref (which is always 

> assumed to be a "safe" input level). 


> In other words, we're confident that we don't have a *logic* problem. We 

> should be correctly modeling all select inputs low as an indeterminate 

> (X) output. The worry is that our timing models do not consider the 

> transition delay between this state and a "normal" driven output. 


> The models should put out Z in this case (which will be treated as X 

> by succeeding gates). It would appear from this description that the 

> restriction really only applies to 3 level stack gates and that 

> regular muxes (two level) should not really need to be restricted this 

> way. Is that so? 

Well, sort of. 

Some of our multiplexer structures accept "mp" inputs at their top level 
and "np" at their second (or equivalently, "mp" on select inputs that get 
internally shifted down one Vbe). These gates have a somewhat different 
vulnerability: if the bases of the select transistor are all "low" 2pf 
signals then the emitters of the select transistors are low enough that 
the NMOS "current sources" will have severely reduced output current at 
certain operating conditions. This would make both outputs tend to float 
high. 

We decided at the csyn/celltest meeting long ago that we were not prepared 
to invest the time required to verify that our timing numbers would be 
correct in cases like this. Even if the normal muxes work fine, we know 
that the muxens have a problem, and now we need a way to reliably differentiate 
between the two cases in csyn. 

We could accomplish this by changing the signal naming convention to make 
the behavior explicit (I can see the rotten fruit flying my way from the 
folks who would have to change a bunch of pin names, then time and verify 


> 


> 
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the resulting cells) or ask for a new csyn feature to let us apply 

certain rules only to certain cells (more rotten fruit, this time from fwo). 

I don't know for certain, but from two's list it looks like it might be 
simpler to buffer a signal or two than to add the new csyn/signame "feature" 
this late in the game. 

Agreed. In fact we had another debate earlier this evening about the 
importance of not making gratuitous changes because of the inevitable 
impact on the critical path. 

Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Thursday, March 16, 1995 2:40 AM 
'wingard (Drew Wingard)' 
'hardheads' 

Re: Csyn Euterpe BOM 247 errors 


Drew Wingard wrote (on Wed Mar 15) : 
Tbr wrote: 

> Drew Wingard wrote (on Wed Mar 15) : 

> 

> The reasoning behind the half -swing requirement is simply that we 
have no 

> way to guarantee that at least one of an "exclusive" set of bits is 
actually 

> high. If a logical "don't care" case temporarily left all 
(full- swing) 

> inputs low, we could run into electrical problems (such as 
saturating 

> the bottom switch in a muxen gate) that would delay the gate's 
response once 

> a select input rose again. A half- swing signal solves the problem 

by 

> raising the "least positive voltage" to that of a vref (which is 
always 

> assumed to be a "safe" input level) . 
> 

> In other words, we're confident that we don't have a *logic* 
problem. We 

> should be correctly modeling all select inputs low as an 
indeterminate 

> (X) output. The worry is that our timing models do not consider 


> transition delay between this state and a "normal" driven output. 
> 

> The models should put out Z in this case (which will be treated as X 

> by succeeding gates) . It would appear from this description that the 

> restriction really only applies to 3 level stack gates and that 

> regular muxes (two level) should not really need to be restricted this 

> way. Is that so? 

Well, sort of. 

Some of our multiplexer structures accept "mp" inputs at their top level 
and "np" at their second (or equivalently , "mp" on select inputs that get 
internally shifted down one Vbe) . These gates have a somewhat different 
vulnerability: if the bases of the select transistor are all "low" 2pf 
signals then the emitters of the select transistors are low enough that 
the NMOS "current sources" will have severely reduced output current at 
certain operating conditions. This would make both outputs tend to float 
high. 

We decided at the csyn/celltest meeting long ago that we were not prepared 
to invest the time required to verify that our timing numbers would be 
correct in cases like this. Even if the normal muxes work fine, we know 
that the muxens have a problem, and now we need a way to reliably differentiate 
between the two cases in csyn. 

We could accomplish this by changing the signal naming convention to make 
the behavior explicit (I can see the rotten fruit flying my way from the 
folks who would have to change a bunch of pin names, then time and verify 
the resulting cells) or ask for a new csyn feature to let us apply 
certain rules only to certain cells (more rotten fruit, this time from fwo) . 


the 
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I don't know for certain, but from fwo's list it looks like it might be 
simpler to buffer a signal or two than to add the new csyn/signame "feature" 
this late in the game. 

Agreed. In fact we had another debate earlier this evening about the importance of not 
making gratuitous changes because of the inevitable impact on the critical path. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


billz (Bill Zuravleff) 

Thursday, March 16, 1995 6:17 AM 

'hopper (Mark Hofmann)' 

'tbr (Tim B. Robinson)'; 'geert (Geert Rosseel)'; 'dickson (Richard Dickson)' 
Need help with NB place and route, again 


hopper , 

Re: rib place and route 

(for the purposes of this note, ignore my requests to get nb_mid a.k.a. nb_mid_new to 
"pack". For the moment, I just want the place and route run to complete through final so 
I can see if there are unroute or timing errors) 

OK, here's the problem: 

nb-passl has no timing errors and (for the purposes of this 
discussion) and acceptable placement. 

In pass2 pifpack moves one or more aligned cells from their original position on the 
extreme right-hand side. Then, there are two cells on the same row with the same 
alignment marker so pim2pif fails with a fatal error. 

Both nb-passl.pim and nb-pass2 . pirn consist of five sections, the last of which -- the 
custom data path on the right side -- begins with 

.xoffset 1450 
.yoffset 470 
.nopifpack 

... so how do I prevent the movement of the aligned cells on the right hand side? I 
thought the .nopifpack directive would do this. 

The log file for this run is in -billz/euterpe/verilog/bsrc/nb/nbgards . log 
with corresponding gards directory ~billz/euterpe/verilog/bsrc/nb/gards . 

Thanks for listening, 
billz 
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From: Herman Chu [hchu@igineer.microunity.com] 

Sent: Thursday, March 16, 1995 11:34 AM 

To: 'Tim B. Robinson'; , woody@igineer'; 'tbe@igineer'; 'dbulfer@igineer'; 'pmayer@igineer' 

Cc: 'pandora@igineer' 

Subject: Re: Euterpe module 


Thermally it shouldn't be a problem, since we will have force air to cool the SDRAM s in 
Pandora as compared to natural convection cooling in Hestia. 


Herman 
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Subject: 


From: 
Sent: 
To: 


Guillermo A. Loyola [gmo@microunity.com] 
Thursday, March 16, 1995 11:49 AM 

'tony@m icrounity.com'; 'tbr@microunity.com'; John Moussouris; 'hayes@microunity.com'; 
'guarino@microunity.com'; •gap@microunity.com'; Craig Hansen; 'Curtis Abbott' 
Re: notes on today's meeting 


- Gmo to verify we can run SPEC in 16MB (or alternatively, in 8MB, in 
which case Tbr is off the hook) . 

Ray and I talked about this (he is really the one running the SPEC benchmarks) , it seems 
like all the cases we have run but one run in *4Meg*, we'll try to pinpoint exactly how 
much memory that one needs. 


Gmo. 
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Subject: 


From: 


Sent: 
To: 

Cc: 


bpw (B. P. Wong) 

Thursday, March 16, 1995 12:36 PM 

'tbr'; 'wingard' 

'hardheads' 

Re: Csyn Euterpe BOM 247 errors 


> Well, sort of. 

> Some of our multiplexer structures accept "mp" inputs at their top 

> level and "np" at their second (or equivalently , "mp" on select inputs 

> that 
get 

> internally shifted down one Vbe) , These gates have a somewhat 

> different 

> vulnerability; if the bases of the select transistor are all "low" 2pf 

> signals then the emitters of the select transistors are low enough 

> that the NMOS "current sources" will have severely reduced output 

> current at certain operating conditions. This would make both outputs 

> tend to 
float 

> high. 

The difference between this condition and an acceptable 3 stack gate is less than 200mV. 
The NMOS sources if out of saturation will become like a resistor and hence does not 
behave like the BJT current sources, i.e. the reduction in current is not as severe as you 
may think. Furthermore, when the mux becomes active one of the sel inputs will be pulled 
high which brings the current source back to its "legal" level. Therefore, if we feel 
that this operating condition is unacceptable then we should question our normal operation 
also! 


bpw 
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From: Tom Eich [tbe@microunity.com] 
Sent: Thursday, March 16, 1995 12:57 PM 
To: 'tor 1 ; 'dbulfer" 

Subject: Re: New rev of Hestia main pcb criteria dwg 

[Following is interchange between Pattie and myself. No doubt that I am 
behind on getting Criteria drawings done for both products, but my question 
to you both is what is the priority? I believe there already exists a 
netlist for Hestia, thus Patties reference to "the other way around". 
-Tom] 

Pattie Mayer wrote: 

>It will be working the other way around, Hestia Main first, then 
>Pandodra Euterpe. 

> 

>snip< 

> 

>-Pattie 

> 

» From tbe@microunity.com Wed Mar 15 19:57:47 1995 
» To: pmayer 

» From: tbe@microunity.com (Tom Eich) 

» Subject: New rev of Hestia main pcb criteria dwg 

» 

» 1 promised I'd assess when 1 could get this to you, and here's my schedule: 

» 

» Thursday: complete and check in Pandora Euterpe criteria drawing 
» Friday: complete and check in Hestia criteria drawing 

» 

» Do you have the netlist ready for Hestia? If the Pandora Euterpe netlist 
» is not ready and hestia is, then perhaps I've got my priorities reversed. 
» Please let me know if you think so. 

» 

» -Tom 

» 

» 

» Tom Eich tbe@microunity.com 

» MicroUnity Systems Engineering, Inc.| 

» 255 Caspian Dr. Sunnyvale, CA 94089 j 

» (408)734-8100, (408)734-8136 fax | 

» 

» 

» 


Tom Eich tbe@microunity.com 
MicroUnity Systems Engineering, Inc.| 
255 Caspian Dr. Sunnyvale, CA 94089 | 
(408)734-8100, (408)734-8136 fax | 
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Subject: 


Sent: 
To: 

Cc: 


From: 


wingard (Drew Wingard) 
Thursday, March 16, 1995 1:55 PM 
'bpw'; 'tor' 
'hardheads' 

Re: Csyn Euterpe BOM 247 errors 


B. P. Wong wrote: 

> Drew wrote : 

> > Well, sort of. 

> > 

> > Some of our multiplexer structures accept "mp" inputs at their top 
level 

> > and "np" at their second (or equivalent ly, "mp" on select inputs 

> > that 
get 

> > internally shifted down one Vbe) . These gates have a somewhat 
different 

> > vulnerability: if the bases of the select transistor are all "low" 

> > 2pf signals then the emitters of the select transistors are low 

> > enough 
that 

> > the NMOS "current sources" will have severely reduced output current 
at 

> > certain operating conditions. This would make both outputs tend to 
float 

> > high. 
> 

> The difference between this condition and an acceptable 3 stack gate 

> is 
less 

> than 200mV. The NMOS sources if out of saturation will become like a 
resistor 

> and hence does not behave like the BJT current sources, i.e. the 
reduction 

> in current is not as severe as you may think. Furthermore, when the 

> mux becomes active one of the sel inputs will be pulled high which 

> brings 
the 

> current source back to its "legal" level. Therefore, if we feel that 
this 

> operating condition is unacceptable then we should question our normal 

> operation also! 

I don't believe that operation at the 'nominal' knob settings (i.e. rcd=6 and 400mV full 
swing) is the issue here. We were more concerned about electrical behavior at higher- 
swing settings where the difference in current source voltage would be much higher. 
There's not much drain- source voltage across the current source if the *highest* select 
input is a *low* 800mV full-swing 2p signal (Vcc - 3*Vbe - 8 0 0mV) . (Yes B.P., one of 
those Vbe's will be at much lower current density due to both parallel connection and 
decreased current source current) . 

The point is *not* whether the gates respond properly once the condition ends. 

The point *is* that we do not characterize the gates in this condition, and therefore we 
cannot assume that all structures with the "e" qualifier will function as expected. This 
was the decision that we took in the csyn/celltest meeting late last year. "E" signals 
inside custom structures are different, and we can easily modify the csyn rules to handle 
those cases. 

I still think that it is simpler, if less elegant, to add a buffer cell to the *only* case 
in Euterpe where this restriction turned out to be an issue. 

It certainly seems a lot easier than proving to ourselves that there are no cases where we 
get into trouble and then convincing csyn to permit only it for only these cells. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig (tau)) 
Thursday, March 16, 1995 2:01 PM 
'Drew Wingard' 
'hardheads'; 'tau' 

Re: Csyn Euterpe BOM 247 errors 


Drew Wingard writes: 
I 

| I still think that it is simpler, if less elegant, to add a buffer cell 
to 

| the *only* case in Euterpe where this restriction turned out to be an 
issue . 

It certainly seems a lot easier than proving to ourselves that there 
are no cases where we get into trouble and then convincing csyn to 
permit 
only 

jit for only these cells. 

I'd agree that one buffer is a small price to pay. An alternative that might even be a 
smaller price is to increase the fanin of the mux by one, and tie the extra select lead to 
vref . 


1 \. 
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From: Tom Eich [tbe@microunity.com] 

Sent: Thursday, March 16, 1995 2:10 PM 

To: 'pmayer (Patricia Mayer)' 

Cc: 'dbulfer 1 ; 'tbr'; 'hopper'; 'albers' 

Subject: Re: New rev of Hestia main pcb criteria dwg 

Per discussion with Tim, and because Howard has adequate rough criteria for 
Pandora Euterpe pcb preliminary layout, and also because Pattie is ready to 
go on Hestia, I will complete the Hestia pcb criteria today and then 
proceed to the Euterpe design. Mark and I pinned Steve Brown down and he 
got the temp, keys extended for the pro/e to allegro interface (needed now 
for the Hestia layout) while a signature issue is resolved, so I am once 
more on the critical path. I anticipate we'll need Dan's help (tomorrow) 
once I've checked in the Hestia drawing, to help Pattie get it into 
Allegro. 

-Tom 


Tom Eich | tbe@microunity.com 

MicroUnity Systems Engineering, Inc.j 
255 Caspian Dr. Sunnyvale, CA 94089 | 
(408)734-8100, (408)734-8 1 36 fax | 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wingard (Drew Wingard) 
Thursday, March 16, 1995 2:23 PM 
'tau' 

'hardheads' 

Re: Csyn Euterpe BOM 247 errors 


Tom Laidig wrote: 

> Drew Wingard writes: 

> I 

> | I still think that it is simpler, if less elegant, to add a buffer 

> | cell 
to 

> | the *only* case in Euterpe where this restriction turned out to be an 
issue . 

> | It certainly seems a lot easier than proving to ourselves that there 
are 

> | no cases where we get into trouble and then convincing csyn to permit 
only 

> | it for only these cells. 
> 

> I'd agree that one buffer is a small price to pay. An alternative 

> that might even be a smaller price is to increase the fanin of the mux 

> by one, and tie the extra select lead to vref . 

Ugh. I was afraid that someone might mention the "vref" solution. This works 
electrically, but my understanding is that the Verilog logic model cannot handle vrefs as 
logically "useful" inputs. We ignore vrefs on OR gates, require that they be tied to the 
(ignored) _n pin on differential inputs, and don't get the nice feature that a vref tied 
to a mux select gives a "default" mux output (like the default case in a C switch 


So, it might work for this case, depending on what Verilog thinks is the logic level of 
vref. I suppose that it would work if Verilog thinks vref is logic 0, but not if logic 1, 
X, or Z. Again, it's a case that we've tried to avoid having to implement /verify, since 
it buys you nothing logically while only electrically guaranteeing a "least positive 
voltage" . 


statement) . 


Drew 
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From: bpw (B. P. Wong) 

Sent: Thursday, March 16, 1995 2:31 PM 

To: 'wingard' 

Cc: 'hardheads' 

Subject: Re: Csyn Euterpe BOM 247 errors 


> 7> 

> > The difference between this condition and an acceptable 3 stack gate 
is less 

> > than 2 00mV. The NMOS sources if out of saturation will become like 

> > a 
resistor 

> > and hence does not behave like the BJT current sources, i.e. the 
reduction 

> > in current is not as severe as you may think. Furthermore, when the 
mux 

> > becomes active one of the sel inputs will be pulled high which 

> > brings 
the 

> > current source back to its "legal" level. Therefore, if we feel 

> > that 
this 

> > operating condition is unacceptable then we should question our 

> > normal operation also! 
> 

> I don't believe that operation at the 'nominal' knob settings (i.e. 
rcd=6 

> and 400mv full swing) is the issue here. We were more concerned about 

> electrical behavior at higher- swing settings where the difference in 

> current source voltage would be much higher . There ' s not much 
drain- source 

> voltage across the current source if the *highest* select input is a 

> *low* 800mV full-swing 2p signal (Vcc - 3*Vbe - 800mV) . (Yes B.P., 
one of 

> those vbe ' s will be at much lower current density due to both parallel 

> connection and decreased current source current) . 

Why do we need to run at 80 0mV? We are barely meeting speed at 4 00mV! 

We used to design to 500mV and soon after that we had to reduce to 400mV to make speed and 
size. If we have to run at 8 00mV the game is over. 

Furthermore, the cells are also not characterized at that large swing. 
> 

> The point is *not* whether the gates respond properly once the 

> condition 
ends . 

> 

> The point *is* that we do not characterize the gates in this 

> condition, 
and 

> therefore we cannot assume that all structures with the "e" qualifier 
will 

> function as expected. This was the decision that we took in the 

> csyn/celltest meeting late last year. »E» signals inside custom 
structures 

> are different, and we can easily modify the csyn rules to handle those 
cases . 

> 

Are we going to start characterizing the cells at the large swing? 

I envision a tool as something that helps me do my job better and not something I have to 
appease inorder to make it work. 

> I still think that it is simpler, if less elegant, to add a buffer 

> cell 


Exhibit C12 


Page 311 of 643 


to 

> the *only* case in Euterpe where this restriction turned out to be an 
issue . 

> It certainly seems a lot easier than proving to ourselves that there 

> are no cases where we get into trouble and then convincing csyn to 

> permit 
only 

> it for only these cells. 

Why add extra circuitry where we don't need. Why can't we put in smarts into the program 
to indicate real problems and only fix those . ? 

bpw 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig (tau)) 

Thursday, March 16, 1995 3:05 PM 

'B. P. Wong' 

'wingard (Drew Wingard)'; 'two (Fred Obermeier)'; 'tbr (Tim B. Robinson)'; 'geert (Geerl 
Rosseel)'; 'tail' 

Re: Csyn Euterpe BOM 247 errors 


B. P. Wong writes: 

Why do we need to run at 800mV? We are barely meeting speed at 4 00mV! 
We used to design to 5 0 0mV and soon after that we had to reduce to 
4 0 0raV to make speed and size. If we have to run at 800mV the game is over. 
Furthermore, the cells are also not characterized at that large swing. 

If for some reason the only way we can make the first rev of euterpe run is at 800mV swing 
and 1/4 speed, this is far better than having it not run at all. Software types can use 
it for testing, investors and potential customers will be more willing to believe we have 
a chance of fixing it to work at speed, etc. Or perhaps we'll decide to do wafer sort 
testing at 8 0 0mV swing; I don't know. 

Are we going to start characterizing the cells at the large swing? 
I envision a tool as something that helps me do my job better and not 
something I have to appease inorder to make it work. 


[Why add extra circuitry where we don't need. Why can't we put in 

j smarts into the program to indicate real problems and only fix those.? 

I dunno about characterizing gates at all knob corners. The (partial) charter of this 
particular tool is to verify that we've connected things with appropriate signal levels 
such that the circuit _should_ work over all knob settings --at some speed. With any 
such tool, there are corner cases where we either have to add smarts to the tool, or 
change the design. The correct decision, obviously, is the one that costs less. We make 
this kind of tradeoff all the time with design rule checkers and every other mechanized 
verification process. In this case, adding one small buffer is a small cost; figuring out 
how to distinguish the OK cases from the bad cases, coding that into csyn, and probably 
munging a bunch of cells to put distinguishing qualifiers into pin names or whatever, 
seems a much higher cost . 


[snip] 


1 V 
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From: 


craig 

Thursday, March 16, 1995 4:35 PM 
'dbulfer pmayer tbe tbr woody' 
'pandora' 

Re: Euterpe module 


Sent: 

To: 

Cc: 


Subject: 


> A potential requirement for 16MB of SDRAM in the Euterpe brick has 

> come up. 
> 

> This can be acheived using 8 4Mx4 parts which Euterpe supports, but 

> the current PCB design does not . It may not be practical to have a 

> single PCB layout support 2 1Mx16, 4 2Mx8 , or 8 4Mx4 parts, but 

> clearly we could have two different PCBs in that case. The most 

> important thing is to be sure we have physical space to accommodate 8 

> SDRAM components and that we can cool them in the module . 
> 

> Tom, pattie, can you look at these issues to make sure the current 

> form factor can accommodate this option if it shoud become a hard 

> requirement? The 4Mx4 part is in the same package as the 2Mx8 . 


Can the pin interface admit the possibility of using 8 2Mx8 parts for a 16 MB memory? This 

requires select pins and additional capacitance on the data pins, but would permit us to 

stock fewer SDRAM part types. It also presumes that 2Mx8 parts are no less available than 
4Mx4 parts. 


> 


> Tim 


Craig 
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From: lisar (Lisa Robinson) 

Sent: Thursday, March 16, 1995 4:55 PM 

To: 'tbr' 

Subject: forwarded message from Dave Conroy 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["2881" "Thu" "16" "March" "1995" "13:39:41" "-0800" "Dave Conroy" "djc " nil "70" "Re: performance testing" 
" A From:" nil nil "3"]) 
Return-Path: <djc> 

Received: from pegasus.microunity.com by gaea.microunity.com (4.1/musel.3) 

idAA04402;Thu, 16 Mar 95 13:39:42 PST 
Received: by pegasus.microunity.com (8.6.10/muse-sw.3) 

idNAA10597; Thu, 16 Mar 1995 13:39:41 -0800 
Message-Id: < 199503 162139.NAA10597@pegasus.microunity.com> 
From: djc (Dave Conroy) 
To: billz 
Cc: lisar, jefftn 

Subject: Re: performance testing 
Date: Thu, 16 Mar 1995 13:39:41 -0800 


Here is an update on the perfomance testing - 

> The first thing I was going to do was verify the operation on hwterp again. 

> Unfortunately I am unable to do that. I have run into two problems with 

> hwterp. 

> 

> First I tried to run the NB tests, the changes that were 

> made to the sync ops in the HW that prevent deadlocks 

> have not made their way into terp yet. Lisa Repka has the info 

> on what needs to be done and is hoping to have it in by Monday nights build. 

> 

> I will try again on Tues. 

> 

The fix is not in yet. Lisa Repka is still working on it. She has it 
essentially in and is in debug at this time. 

> Next 1 moved on to the dcache performance tests. I started getting 

> unexpected exceptions when doing dcache ops. I have looked at the hwterp 

> traces and can't see anything wrong with what is being attempted. It dies 

> on the second dcache access. I have sent an e-mail off to the simulator 

> folks. 

The problem was mine. I had made some changes for the new tag spacing and 
when I made them the simulator still had the old spacing. Now that the 
simulator has been updated to the new spacing I just needed to update the 
conditional compile statements to reflect that. 

I have done that and the test still passes on hwterp. I ran it on terp 
and have a trace printout. I have edited two files 

~djc/s w/stb/stand/diag/memh i/cached . trace 
~djc/sw/stb/stana7diag/memhi/uncached.trace 
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To include just the timing loops for the cached and uncached sections of 
the test. These show exactly the sequence of instructions and some guidance 
on how long each operation took on the simulator. 

The next step is probably to analyze the terp trace files and see if anything 
obvious leaps out. If it doesn't then a more thorough analysis of the terp 
vs. HW simulator traces would seem in order. 

Lisa has run the HW simulator on this same test The results for both simulators 
are listed below: 

hwterp : Uncached elapsed time - Cached elapased time = 4840 
HW Sim : Uncached elapsed time - Cached elapased time = 3650 

> 

> The next item was to summarize what was being done in the dcachejperfjdlt 

> test. 

> 

> There is a loop of 5 loads from 5 different addresses. Each address is in 

> a different cache line. The cache lines are filled prior to the timing test. 

> Then a loop is executed that does a load from each of the 5 addresses. The 

> loop is executed 20 times. The returned data is then checked to make sure 

> the loads have completed. 
> 

> This process is repeated but the addresses used are in an uncached section 

> of DRAM. 

> 

> The difference between the time taken for the uncached and cached 

> accesses is compared to see if it falls within an expected range. 

> If it does not then an error is generated and the actual and expected values 

> are printed. 

> 


The ball is now in your court, I await your return volley, djc 
End of forwarded message 
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From: bill (William Herndon) 

Sent: Thursday, March 16, 1995 4:59 PM 

To: 'wingard'; 'bpw* 

Cc: 'hardheads' 

Subject: Re: Csyn Euterpe BOM 247 errors 


> From bpw Thu Mar 16 11:31:32 1995 

> Date: Thu, 16 Mar 1995 11:31:05 -0800 

> From: bpw (B . P. Wong) 

> To: wingard 

> Subject: Re: Csyn Euterpe BOM 24 7 errors 

> Cc : hardheads 

> Content -Length: 257 9 

> 

> > > 

> > > The difference between this condition and an acceptable 3 stack 

> > > gate 
is less 

> > > than 2 00mV. The NMOS sources if out of saturation will become 

> > > like 
a resistor 

> > > and hence does not behave like the BJT current sources, i.e. the 
reduction 

> > > in current is not as severe as you may think. Furthermore, when 

> > > the 
mux 

> > > becomes active one of the sel inputs will be pulled high which 
brings the 

> > > current source back to its "legal" level. Therefore, if we feel 
that this 

> > > operating condition is unacceptable then we should question our 
normal 

> > > operation alsol 

> > 

> > I don't believe that operation at the 'nominal 1 knob settings (i.e. 
rcd=6 

> > and 400mv full swing) is the issue here. We were more concerned 

> > about electrical behavior at higher- swing settings where the 

> > difference in current source voltage would be much higher. There's 

> > not much 
drain- source 

> > voltage across the current source if the *highest* select input is a 

> > *low* 800mV full-swing 2p signal (Vcc - 3*Vbe - 8 0 0mV) . (Yes B.P., 
one of 

> > those Vbe's will be at much lower current density due to both 

> > parallel connection and decreased current source current) . 

> 

> Why do we need to run at 800mV? We are barely meeting speed at 4 00mV! 

> We used to design to 500mV and soon after that we had to reduce to 

> 4 0 0mV to make speed and size. If we have to run at 8 0 0mV the game is over. 

> Furthermore, the cells are also not characterized at that large swing. 

> 

> > 

> > The point is *not* whether the gates respond properly once the 
condition ends . 

> > 

> > The point *is* that we do not characterize the gates in this 
condition, and 

> > therefore we cannot assume that all structures with the "e" 

> > qualifier 
will 

> > function as expected. This was the decision that we took in the 

> > csyn/celltest meeting late last year. "E" signals inside custom 
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structures 

> > are different, and we can easily modify the csyn rules to handle 

> > those 
cases . 

> > 

> Are we going to start characterizing the cells at the large swing? 

> I envision a tool as something that helps me do my job better and not 

> something I have to appease inorder to make it work. 
> 

> > I still think that it is simpler, if less elegant, to add a buffer 
cell to 

> > the *only* case in Euterpe where this restriction turned out to be 

> > an 
issue . 

> > It certainly seems a lot easier than proving to ourselves that there 
are 

> > no cases where we get into trouble and then convincing csyn to 

> > permit 
only 

> > it for only these cells. 
> 

> Why add extra circuitry where we don't need. Why can't we put in 

> smarts into the program to indicate real problems and only fix those.? 
> 

> bpw 


My preferences as far as operation is concerned 1. only have half swing inputs 2. allow 
full swing inputs, no reference 3. put in the reference 

I don't think anything too disastrous happens with full swing inputs and no reference, but 
i'd like to avoid another set of operating conditions if possible. 

If we have to have another set of operating conditions, I think the hazards with a vref 
input are a bit higher than the hazards of getting the n current source out of the linear 
region. If it were a bipolar current source, i would be more concerned about getting out 
of the current source region. 

If it is only a few gates, then the loss of adding extra stuff for half swing inputs ought 
to be minimal.. If it turns out its lots of gates then i would allow full swing inputs, no 
reference input. 
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Sent: 

To: 

Cc: 


Subject: 


From: 


mws (Mark Semmelmeyer) 
Thursday, March 16, 1995 5:21 PM 
'wingard'; 'bpw'; 'bill* 
'hardheads' 

Re: Fullswing selects; Csyn Euterpe BOM 247 errors 


If people want to discuss characterization methodology as justified by general 
considerations, that is fine, but don't let the one csyn case here influence the 
discussion, because it is easy to fix and I am going to fix it. 

The more helpful longer term improvement would be a mux that allowed its selects to all be 
off, or better yet random, and then still recover to valid operation in the next clock 
cycle. This would simplify certain control logic. But I know this is too hard on 
methodology and is probably very unportable across circuit/logic families. 
Thus I don't request it. improvements less than that are unlikely to be worth their 
trouble, so I don't request them either. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


craig (Craig Hansen) 

Thursday, March 16, 1995 5:35 PM 

'dbulfer'; 'pmayer'; 'toe'; 'tbr'; 'woody' 

'pandora' 

Re: Euterpe module 


> A potential requirement for 16MB of SDRAM in the Euterpe brick has 

> come up. 
> 

> This can be acheived using 8 4Mx4 parts which Euterpe supports, but 

> the current PCB design does not. It may not be practical to have a 

> single PCB layout support 2 1Mx16, 4 2Mx8 , or 8 4Mx4 parts, but 

> clearly we could have two different PCBs in that case. The most 

> important thing is to be sure we have physical space to accommodate 8 

> SDRAM components and that we can cool them in the module. 
> 

> Tom, pattie, can you look at these issues to make sure the current 

> form factor can accommodate this option if it shoud become a hard 

> requirement? The 4Mx4 part is in the same package as the 2Mx8 . 


Can the pin interface admit the possibility of using 8 2Mx8 parts for a 16 MB memory? This 
requires select pins and additional capacitance on the data pins, but would permit us to 
stock fewer SDRAM part types. It also presumes that 2Mx8 parts are no less available than 
4Mx4 parts. 


> 


> Tim 


Craig 
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Subject: 


Sent: 

To: 

Cc: 


From: 


fwo (Fred Obermeier) 

Thursday, March 16, 1995 6:02 PM 

'hardheads' 

'fwo' 

Planned 5pm disturbance. 


In order to fix a number of exclusive input swing check csyn errors in Euterpe, we plan to 
change the sel_alpeh signal name in eam2f f dhl6sllx2a cell to sel_alp2eh at 5pm today. 
This change will effect one schematic, one layout, and one verilog file: 

proteus/ged/ea/eam2f fdhl6sllx2a/body . 1 . 1 

proteus/ged/ea/eam2f f dhl6sllx2a/spice .1.1 

proteus/ged/ea/eam2f fdhl6sllx2a/spice_cn. l . 1 

proteus/compass/ layout s/eam2f f dhl6sllx2a. ly 

proteus/exlax/elibsrc/eam2f f . V 

Timing files for this cell should also be regenerated. 
Let me know if we should delay this release . 


Thanks 
Fred. 
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From: tbr (Tim B. Robinson) 

Sent: Thursday, March 16, 1995 7:45 PM 

To: 'bpw (B. P. Wong)' 

Cc: 'hardheads'; 'wingard' 

Subject: Re: Csyn Euterpe BOM 247 errors 


B. P. Wong wrote (on Thu Mar 16) : 

> Well, sort of. 
> 

> Some of our multiplexer structures accept "mp" inputs at their top level 

> and "np" at their second (or equivalent ly, 11 mp" on select inputs that get 

> internally shifted down one Vbe) . These gates have a somewhat different 

> vulnerability: if the bases of the select transistor are all "low" 

2pf 

> signals then the emitters of the select transistors are low enough that 

> the NMOS "current sources" will have severely reduced output current at 

> certain operating conditions. This would make both outputs tend to float 

> high. 

The difference between this condition and an acceptable 3 stack gate is less 
than 2 0 0mV. The NMOS sources if out of saturation will become like a resistor 
and hence does not behave like the BJT current sources, i.e. the reduction 
in current is not as severe as you may think. Furthermore, when the mux 
becomes active one of the sel inputs will be pulled high which brings the 
current source back to its "legal" level. Therefore, if we feel that this 
operating condition is unacceptable then we should question our normal 
operation also! 

Isn't there also the consideration that for test, with no space transformer and poor power 
distribution we may have to turn the nominal swing to 90 0mV? 

Of course in this case speed is not a primary concern. 

Tim 
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From: bill (William Herndon) 

Sent: Thursday, March 16, 1995 7:53 PM 

To: 'bpw'; 'tbr' 

Cc: 'hardheads'; 'wingard' 

Subject: Re: Csyn Euterpe BOM 247 errors 


> From tbr Thu Mar 16 16:45:20 1995 

> Date: Thu, 16 Mar 1995 16:44:51 -0800 

> From: tbr (Tim B. Robinson) 

> To: bpw (B. P. Wong) 

> Cc: hardheads, wingard 

> Subject: Re: Csyn Euterpe BOM 247 errors 

> Content -Length: 13 96 


> B . P. Wong wrote (on Thu Mar 16) : 
> 

> > Well, sort of. 

> > 

> > Some of our multiplexer structures accept "rap" inputs at their 

> top 
level 

> > and "np" at their second (or equivalently , "mp" on select inputs 
that get 

> > internally shifted down one Vbe) . These gates have a somewhat 
different 

> > vulnerability: if the bases of the select transistor are all "low" 
2pf 

> > signals then the emitters of the select transistors are low 

> enough 
that 

> > the NMOS "current sources" will have severely reduced output 
current at 

> > certain operating conditions. This would make both outputs tend 

> to 
float 

> > high. 

> 

> The difference between this condition and an acceptable 3 stack 

> gate 
is less 

> than 200mV. The NMOS sources if out of saturation will become like 

> a 

resistor 

> and hence does not behave like the BJT current sources, i.e. the 
reduction 

> in current is not as severe as you may think. Furthermore, when 

> the 
mux 

> becomes active one of the sel inputs will be pulled high which 

> brings 
the 

> current source back to its "legal" level. Therefore, if we feel 

> that 
this 

> operating condition is unacceptable then we should question our 
normal 

> operation also! 
> 

> Isn't there also the consideration that for test, with no space 

> transformer and poor power distribution we may have to turn the 

> nominal swing to 900mV? 
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> Of course in this case speed is not a primary concern. 
> 

> Tim 
> 

The 90 0mv would presumably come with minimum current setting this minimizes the drop 
accross the current source, also i would assume at 900mv we could increase the power 
supply voltage if current source clamping is an issue 
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From: bpw (B. P. Wong) 

Sent: Thursday, March 16, 1995 7:54 PM 

To: 'tbr' 

Cc: 'hardheads'; 'wingard' 

Subject: Re: Csyn Euterpe BOM 247 errors 


> Isn't there also the consideration that for test, with no space 

> transformer and poor power distribution we may have to turn the 

> nominal swing to 90 0mV? 
> 

> Of course in this case speed is not a primary concern. 
> 

> Tim 

> 

You run the risk of saturating the clock BJTs in the orlatch. This was the very problem 
we were trying to avoid in the mux latch. Since this is not a real operating condition it 
should just be something to watch out, we do not latch up the chip during the test. 

bpw 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 16, 1995 10:53 PM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/ctioi BOM 22.0 initiated by dickson completed @ Thu Mar 16 
19:51:00 PST 1995 with exit status 0.. chip 
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From: 


tbr 


To: 


Sent: 


Friday, March 17, 1995 1:04 AM 
'torn (Tom Laidrg (tau)' 


Cc: 


Subject: 


'hardheads'; 'tau'; 'Drew Wingard' 
Re: Csyn Euterpe BOM 247 errors 


Follow Up Flag: Follow up 
Flag Status: Red 

tau wrote (on Thu Mar 16): 

Drew Wingard writes: 
I 

|I still think that it is simpler, if less elegant, to add a buffer cell to 

jthe *only* case in Euterpe where this restriction turned out to be an issue. 

jit certainly seems a lot easier than proving to ourselves that there are 

jno cases where we get into trouble and then convincing csyn to permit only 

jit for only these cells. 

I'd agree that one buffer is a small price to pay. An alternative that 
might even be a smaller price is to increase the fanin of the mux by 
one, and tie the extra select lead to vref. 

Definitely not allowed by our current rules. The simulation model 
won't handle it. We don't have a logic 1/2 to use for vref. 


Tim 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Friday, March 17, 1995 1:06 AM 
Tom Eich' 

'albers'; 'dbulfer'; 'hopper'; 'pmayer (Patricia Mayer)' 
Re: New rev of Hestia main pcb criteria dwg 


Follow Up Flag: Follow up 
Flag Status: Completed 

Tom Eich wrote (on Thu Mar 16): 

Per discussion with Tim, and because Howard has adequate rough criteria for 
Pandora Euterpe pcb preliminary layout, and also because Pattie is ready to 
go on Hestia, I will complete the Hestia pcb criteria today and then 
proceed to the Euterpe design. Mark and I pinned Steve Brown down and he 
got the temp, keys extended for the pro/e to allegro interface (needed now 
for the Hestia layout) while a signature issue is resolved, so I am once 
more on the critical path. I anticipate we'll need Dan's help (tomorrow) 
once I've checked in the Hestia drawing, to help Pattie get it into 
Allegro. 

Thank's torn. Who's signature are we stuck for on the pro/e interface? 


Tim 
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From: 


tbr 


To: 


Cc: 

Subject: 


Sent: 


Friday, March 17, 1995 1:15 AM 
'wingard (Drew Wingard)' 
'hardheads'; 'tau' 

Re: Csyn Euterpe BOM 247 errors 


Follow Up Flag: Follow up 
Flag Status: Red 

Drew Wingard wrote (on Thu Mar 16): 

Tom Laidig wrote: 

> Drew Wingard writes: 
>l 

> [I still think that it is simpler, if less elegant, to add a buffer cell to 

> jthe *only* case in Euterpe where this restriction turned out to be an issue. 

> jit certainly seems a lot easier than proving to ourselves that there are 

> jno cases where we get into trouble and then convincing csyn to permit only 

> jit for only these cells. 


> I'd agree that one buffer is a small price to pay. An alternative that 

> might even be a smaller price is to increase the fanin of the mux by 

> one, and tie the extra select lead to vref. 

Ugh. I was afraid that someone might mention the "vref solution. This 
works electrically, but my understanding is that the Verilog logic model 
cannot handle vrefs as logically "useful" inputs. We ignore vrefs on 
OR gates, require that they be tied to the (ignored) _n pin on differential 
inputs, and don't get the nice feature that a vref tied to a mux select 
gives a "default" mux output (like the default case in a C switch statement). 

So, it might work for this case, depending on what Verilog thinks is the 
logic level of vref. I suppose that it would work if Verilog thinks 
vref is logic 0, but not if logic 1, X, or Z. Again, it's a case that 
we've tried to avoid having to implement/verify, since it buys you nothing 
logically while only electrically guaranteeing a "least positive voltage". 


Back in the original mnemo days we did allow this. In that case we 

required that if used, the vref was always on the 0 select input. 

We then ignored that select input, and computed a replacement value as 

the nor of all the other select inputs. This had the effect that if 

no select inputs were asserted, the vref leg is chosen. However, that 

has the major disadvantage that if the vref option is not being used, 

we are actually ignoring the logic state of the 0 input. 

It turned out that there were only two places in the design where we 
actually had the vref. On Euterpe, we decided to change the rules 
becuase the perceived advantage of being able to use the VREF 
was outweighed by the verification risk of not checking the 0th select 
input properly. In fact we have no static check that the one hot rule 
is obeyed, rather we have to rely on out verification vector coverage 
detecting a problem if we violate the rule. The model will produce 
X's if there are no selects asserted, or if there are multiple selects 


> 
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asserted and the corresponding data inputs are not identical. This 
accurately reflects what the real circuit would do. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Friday, March 17, 1995 1:15 AM 
'wingard (Drew Wingard)' 
'hardheads'; *tau' 

Re: Csyn Euterpe BOM 247 errors 


Drew Wingard wrote (on Thu Mar 16) : 

Tom Laidig wrote: 

> Drew Wingard writes: 
> 

> I still think that it is simpler, if less elegant, to add a buffer cell to 

> the *only* case in Euterpe where this restriction turned out to be an issue. 

> It certainly seems a lot easier than proving to ourselves that there are 

> no cases where we get into trouble and then convincing csyn to permit only 

> it for only these cells. 
> 

> I'd agree that one buffer is a small price to pay. An alternative that 

> might even be a smaller price is to increase the fanin of the mux by 

> one, and tie the extra select lead to vref . 

Ugh. I was afraid that someone might mention the "vref" solution. 
This 

works electrically, but my understanding is that the Verilog logic model 
cannot handle vrefs as logically "useful" inputs. We ignore vrefs on 
OR gates, require that they be tied to the (ignored) _n pin on differential 
inputs, and don't get the nice feature that a vref tied to a mux select 
gives a "default" mux output (like the default case in a C switch statement) . 

So, it might work for this case, depending on what Verilog thinks is the 
logic level of vref. I suppose that it would work if Verilog thinks 
vref is logic 0, but not if logic 1, X, or Z . Again, it's a case that 
we've tried to avoid having to implement /verify, since it buys you nothing 
logically while only electrically guaranteeing a "least positive voltage". 


Back in the original mnemo days we did allow this. In that case we required that if used, 
the vref was always on the 0 select input . 

We then ignored that select input, and computed a replacement value as the nor of all the 
other select inputs. This had the effect that if no select inputs were asserted, the vref 
leg is chosen. However, that has the major disadvantage that if the vref option is not 
being used, we are actually ignoring the logic state of the 0 input. 

It turned out that there were only two places in the design where we actually had the 
vref. On Euterpe, we decided to change the rules becuase the perceived advantage of being 
able to use the VREF was outweighed by the verification risk of not checking the Oth 
select input properly. In fact we have no static check that the one hot rule is obeyed, 
rather we have to rely on out verification vector coverage detecting a problem if we 
violate the rule. The model will produce X's if there are no selects asserted, or if 
there are multiple selects asserted and the corresponding data inputs are not identical. 
This accurately reflects what the real circuit would do. 


Tim 
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From: Tom Eich [tbe@microunity.com] 
Sent: Friday, March 17, 1995 1:16 AM 
To: 'tbr (Tim B. Robinson)' 

Cc: 'albers'; 'dbulfer*; 'hopper'; 'pmayer (Patricia Mayer)' 
Subject: Re: New rev of Hestia main pcb criteria dwg 

>Tom Eich wrote (on Thu Mar 16): 

> 

> Per discussion with Tim, and because Howard has adequate rough criteria for 

> Pandora Euterpe pcb preliminary layout, and also because Pattie is ready to 

> go on Hestia, I will complete the Hestia pcb criteria today and then 

> proceed to the Euterpe design. Mark and I pinned Steve Brown down and he 

> got the temp, keys extended for the pro/e to allegro interface (needed now 

> for the Hestia layout) while a signature issue is resolved, so I am once 

> more on the critical path. I anticipate we'll need Dan's help (tomorrow) 

> once I've checked in the Hestia drawing, to help Pattie get it into 

> Allegro. 
> 

>Thank's torn. Who's signature are we stuck for on the pro/e interface? 

> 

>Tim 

I don't even know (or want to...). Steve Brown is taking care of it. 
-Tom 


Tom Eich | tbe@microunity.com 

MicroUnity Systems Engineering, Inc.| 
255 Caspian Dr. Sunnyvale, CA 94089 | 
(408)734-8100, (408)734-8136 fax | 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Friday, March 17, 1995 1:20 AM 

'bpw(B. P. Wong)' 

'hardheads'; 'wingard' 

Re: Csyn Euterpe BOM 247 errors 


B. P. Wong wrote (on Thu Mar 16) : 


> > 


> > The difference between this condition and an acceptable 3 stack gate is less 

> > than 200mV. The NMOS sources if out of saturation will become like a resistor 

> > and hence does not behave like the BJT current sources, i.e. the reduction 

> > in current is not as severe as you may think. Furthermore, when the mux 

> > becomes active one of the sel inputs will be pulled high which brings the 

> > current source back to its "legal" level. Therefore, if we feel that this 

> > operating condition is unacceptable then we should question our normal 

> > operation also! 
> 

> I don't believe that operation at the 'nominal 1 knob settings (i.e. 
rcd=6 

> and 400mv full swing) is the issue here. We were more concerned about 

> electrical behavior at higher- swing settings where the difference in 

> current source voltage would be much higher. There's not much drain- source 

> voltage across the current source if the *highest* select input is 

> a *low* 800mV full-swing 2p signal (Vcc - 3*Vbe - 8 00mV) . (Yes B.P., one of 

> those Vbe's will be at much lower current density due to both parallel 

> connection and decreased current source current) . 

Why do we need to run at 800mV? We are barely meeting speed at 4 00mVJ 
We used to design to 5 0 0mV and soon after that we had to reduce to 4 00mV 
to make speed and size. If we have to run at 800mV the game is over. 
Furthermore, the cells are also not characterized at that large swing. 

Only for test, where we know that voltage drops across the die will mean lower swings will 
not give any noise margin. 


> The point is *not* whether the gates respond properly once the condition ends. 


> The point *is* that we do not characterize the gates in this condition, and 

> therefore we cannot assume that all structures with the "e" qualifier will 

> function as expected. This was the decision that we took in the 

> csyn/celltest meeting late last year. "E" signals inside custom structures 

> are different, and we can easily modify the csyn rules to handle those cases. 
> 

Are we going to start characterizing the cells at the large swing? 

I envision a tool as something that helps me do my job better and not 

something I have to appease inorder to make it work. 

> I still think that it is simpler, if less elegant, to add a buffer cell to 

> the *only* case in Euterpe where this restriction turned out to be an issue. 

> It certainly seems a lot easier than proving to ourselves that there are 

> no cases where we get into trouble and then convincing csyn to permit only 

> it for only these cells. 

Why add extra circuitry where we don't need. Why can't we put in smarts 
into the program to indicate real problems and only fix those . ? 

I agree it's inelegant, but we ery trying to freeze the rules in order to get the job 
completed. We have had a couple of changes in the last week, which while innocent on the 
surface have cost us time because of the need to rebuild the snapshot for pin name 
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updates . 
Tim 
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From: tbr 

Sent: Friday, March 17, 1995 1:24 AM 

To: 'brianl (Brian Lee)' 

Cc: 'hopper (Mark Hofmann)' 

Subject: missed staff meeting 

Follow Up Flag: Follow up 

Flag Status: Completed 


Brian Lee wrote (on Thu Mar 16): 
Hi, 

Fred just reminded me that it was Th. Sorry I missed the meetings. I 
was here, but got too engrossed in some work and totally forgot. 


No problem. I talked a little about Euterpe logic verification status 
(we're late . . .) but nothing else of significance was discussed. 

Tim 
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From: 


tbr 


Subject: 


To: 


Sent: 


Cc: 


Friday, March 17, 1995 1:37 AM 
'bill (William Herndon)' 
'bpw'; 'hardheads'; 'wingard' 
Re: Csyn Euterpe BOM 247 errors 


Follow Up Flag: Follow up 
Flag Status: Red 

William Herndon wrote (on Thu Mar 16): 

If it is only a few gates, then the loss of adding extra stuff for half swing 
inputs ought to be minimal.. If it turns out its lots of gates then i would 
allow full swing inputs, no reference input. 

One 2s buffer will fix it. It's a nit. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Friday, March 17, 1995 1:37 AM 

'bill (William Herndon)' 

'bpw'; 'hardheads'; 'wingard' 

Re: Csyn Euterpe BOM 247 errors 


William Herndon wrote (on Thu Mar 16) : 

If it is only a few gates, then the loss of adding extra stuff for half swing 
inputs ought to be minimal.. If it turns out its lots of gates then i would 
allow full swing inputs, no reference input. 

One 2s buffer will fix it. It's a nit. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Friday, March 17, 1995 1:43 AM 

'craig (Craig Hansen)' 

'dbulfer'; 'pandora'; 'pmayer'; 'tbe'; 'woody' 

Re: Euterpe module 


Craig Hansen wrote (on Thu Mar 16) : 

> A potential requirement for 16MB of SDRAM in the Euterpe brick has 

> come up. 
> 

> This can be acheived using 8 4Mx4 parts which Euterpe supports, 

> but the current PCB design does not. It may not be practical to have 

> a single PCB layout support 2 1Mx16, 4 2Mx8, or 8 4Mx4 parts, but 

> clearly we could have two different PCBs in that case. The most 

> important thing is to be sure we have physical space to accommodate 8 

> SDRAM components and that we can cool them in the module. 
> 

> Tom, pattie, can you look at these issues to make sure the current 

> form factor can accommodate this option if it shoud become a hard 

> requirement? The 4Mx4 part is in the same package as the 2Mx8 . 


Can the pin interface admit the possibility of using 8 2Mx8 parts 
for a 16 MB memory? This requires select pins and additional 
capacitance on the data pins, but would permit us to stock 
fewer SDRAM part types. It also presumes that 2Mx8 parts are 
no less available than 4Mx4 parts. 

We don't have the select lines. As far as availability goes, 2Mx8 is definitely the most 
common, but I think 4Mx4 is a close second. 1Mx16 was single sourced in the first 
generation, though most vendors are planning on introducing them in the second round. 


> 


> 


Tim 


Tim 
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From: Potatoe Chip [chip@rhea] 

Sent: Friday, March 17, 1995 1:50 AM 

To: 'Potatoe Chip' 

Subject: pager log message 


page f rom ' chip to geert: 

Release euterpe/verilog/bsrc/cp BOM 45.0 initiated by dickson completed @ Thu Mar 16 
22:49:13 PST 1995 with exit status 0.. chip 

lock read: File exists 
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From: Potatoe Chip [chip@rhea] 

Sent: Friday, March 17, 1995 1:56 AM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc BOM 255.0 initiated by dickson completed e Thu Mar 16 
22:55:22 PST 1995 with exit status 0.. chip 
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From: woody (Jay Tomlinson) 

Sent: Friday, March 17, 1995 10:48 AM 

To: 'euterpe-checkins-dist'; 'lisar'; 'tor'; 'torn' 

Subject: euterpe/verilog/bsrc/gt Makefile gtsnake.V gtspmatchlate.Veqn pimlib.pl 
Update of /p/c vsroot/euterpe/verilog/bsrc/gt 

In directory gamorra:/N/auspex6/s20/woody/chip/euterpe/verilog/bsrc/gt 

Modified Files: 

Makefile gtsnake.V gtspmatchlate.Veqn pimlib.pl 
Log Message: 

Fix for icacheharder2 and icache_stress. 
Placement updated. 

icacheharder2_V tabbed. 
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From: woody (Jay Tomlinson) 

Sent: Friday, March 17,19954:17PM 

To: 'tor' 

Subject: euterpe module compile 
Tim, 

Dan has not yet released the new chips__prt generator, because he has to decide 
how to handle the 'flag body' parts (such as dgnd) which don't have a .gyg 
file. 

woody 
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From: 
Sent: 
To: 

Subject: 


paulb {Paul Berry) 

Friday, March 17, 1995 4:58 PM 

•pandora' 

Notes from mtg 95-3-10 


[As usual, the fancy version is in /u/chip/pandora/notes] 
March 10, 1995 

Present: Tim Robinson, David Bulfer, Graham Mostyn, Lisa Robinson, Guillermo Loyola, Tom 
Eich, Geert Rosseel, Johnny Mudge. 


Gmo. The issue is when will hardware be available to the software 
developers : 

How best to use software development time before hardware is available, how much time 
there will be after h/w is available. 

PCB layout issues 


Lisa is adjusting the schedule to take account of new estimates. 
Verification 


Lisa: There have been difficulties running configuration test in Verilog; they are 
extremely slow. Veena has been working on a method to load an advance configuration for 
the Verilog, and this may speed up the processing of tests on Verilog. 

PCI testing has not progressed, mainly because the design is not yet complete; and testing 
will be done from the top level. Top-level simulation of the PCI is required because the 
tests assume the existence of the rest of the Mnemo functionality (so the tests can't 
reasonably be partitioned). Since the Verilog tester can't contact the Ikos, it will not 
be possible to run PCI tests unless there is a VHDL version of the PCI interface. 

So PCI testing is basically waiting for completion of the Mnemo design. 
Resources 

needed for Mnemosyne compete with those needed for Euterpe. 


Tim. We had hoped to freeze Euterpe design by 3/15, but it no longer seems 

possible to do so by that date. We should then review outstanding bugs and discuss 
compromises . 

Lisa: Hardware tests are making good progress; 90% of the bugs found have been in the 
testing code rather than in the hardware. 


Geert: Euterpe routing/ timing decisions are progressing but not fast enough. Four weeks 
ago, the number of outstanding disconnects was 5,400; now it's down to 3,000, and are 
being completed at about 3 00 a week. Geert plus Richard Dixon and Bill Z are the only 
people available full-time for this work. 

Euterpe is about ready for the final physical verification steps, Design Rule Checks 
(DRC) and Layout vs. Schematic (LVS) . 

Debugging metal 


Lisa: What will we use for debugging metal? Since the process bring-up won't be done on 
Euterpe, can we commit to metal masks before metal bring-up? It might be necessary to 


Schedule 


Schedule 


Routing 
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scrap masks that were made too much before process bring- up. 

What is the vehicle for fab debug? Perhaps Orchis: it is comparatively simple (it's just a 
RAM, more customized than the other chips. Castor; Pollux; Calliope- 0 might also serve. 
But under current rates of progress in design, Mnemosyne would still be first. 

PCBs 

Pandora PCBs. Tom: Still estimating 5/16. Have adopted larger but fewer fans, using a 
radial impeller. Should have heat sinks in about four weeks. 

Two boards that have Mnemosyne modules 


In addition to its use in Pandora as memory controller {where Mnemosyne is 

mounted directly on the backplane) , there are two configurations of Mnemosyne on an 
expansion card: 

o PCI -ISA Bridge 

Used within Pandora 

Connectors for : 
PCI bus 
ISA bus 

Hermes channel (to the Pandora's onboard 

Euterpe) 

The ISA interface on this card permits 
communication with an 

additional 5 cards on the Pandora's ISA bus 

The PCI interface on this card permits 
communication with an 

additional 3 cards on the Pandora' a PCI bus 

o PCI -Hermes link for a PC 

Mounted on the PCI bus of a PC {or any machine 

with a PCI slot) 

Provides a link from the PC to the Hermes channel 
(presumably, to the Hermes port of a Hestia, or to a Pandora) 

Heat dissipation 


The heat sink for Mnemosyne on a PCI board is 4 inches square. Mounting in a PC imposes 
height and heat restrictions; we are assuming that the PC -mounted PCI- to -Hermes version 
can be restricted to 20 watts, and can rely on convective cooling {that is, without 
additional fans) . 

The version mounted within Pandora can have more RAM and can produce more 
heat. 

Positioning of the SDRAM on the Euterpe module 


It may be desirable to return to the original orientation. The position was turned to 
allow room for the analog processing in Hestia, but since that won't be included in the 
Pandora version, the original orientation may be retained. 

Coordination of projects 


Lisa: Can we revive regular schedule meetings with Mouss. There's an advantage to having 
regular reviews of schedule and status, and fore reviewing interdependencies . Graham: Yes, 
regular meetings desirable. 

Impact of design changes on software. 
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Tim: The original plan was to bring up Unix on an X86 as a vehicle for developing device 
drivers, and then to bring up UNIX on Euterpe on a Hestia board, with the Cronus 
implementation of Hestia left until later. But now it seems that Euterpe is the gating 
item, so it will be possible to use the Euterpe module in Pandora rather than in Hestia. 

Cronus design 


To what extent should Cronus be designed with features that differ from Euterpe? 
The issue is that Euterpe assumed the existence of Mnemosyne and Calliope chips 
communicating via Hermes, but Cronus might have to operate in a context where none of 
those exist. Should Cronus then be modified to accommodate that different context? For 
example, at low clock rates, having Cronus retain the Euterpe design for I/O might not 
make sense. But one of the reasons for building Cronus was to demonstrate a portable 
design by implementing the same chip in more than one place and by more than one process. 

David: We should change as little as possible. Many of the possible changes, while visible 
to Verification, would have no visible effect on software or software testing. 
Gmo: Yes, but changes in I/O speed also affect memory access, and will affect benchmarks 
across the board. 

If Cronus turns out to be the first chip available for testing, it certainly should have 
as few differences as possible from Euterpe. 

Decision: The Cronus design should remain exactly the same as the 
Euterpe design. 

A 3.3V implementation would be preferable. 

Cronus foundry 

Geert: The plan to revive the cross-bar data-path (XDP) for Cronus has been abandoned. 

There are two options for a Cronus process: 

o 5V at 4 00 MHz, for about 15 0 watts 

o 3.3 V at 200 MHz for about 30 watts 

(These might imply different boards, different heat sinks) Perhaps we should do only the 
3 . 3V version? 

David: Either way, we have adequate power supply. 

David thought VTI would be able to do a 3.3V version using a three- layer process. 


End Included Message 
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From: Tom Eich [tbe@microunity.com] 

Sent: Friday, March 17, 1995 6:29 PM 

To: 'Herman Chu' 

Cc: 'paulb@microunity.com'; 'pandora@microunity.com' 

Subject: Re: Notes from mtg 95-3-10 


>>Paul Berry (paulb) wrote: 
>> 

>>Heat dissipation 



>>The heat sink for Mnemosyne on a PCI board is 4 inches square. 

>>Mounting 

in a 

>PC 

>> imposes height and heat restrictions; we are assuming that the 
PC- mounted 

>>PCI-to-Hermes version can be restricted to 2 0 watts, and can rely on 
>convective 

>>cooling (that is, without additional fans) . 
» 

>For the PC -mounted PCI- to- Hermes Mn, that will be relying on natural 

>convection cooling, the heat sink will be significantly larger than 

4inx4in 

> square . 

> 

This is true of course, and somehow the message I gave at the meeting, which was that the 
4x4" heat sink would not need a local, heat sink mounted fan, but would have forced 
convection from the PCI area system fan, go garbled here. 

» 

>>The version mounted within Pandora can have more RAM and can produce 

more 

>>heat . 

>> 

> 

>This is a new one to me J All the heat sink designs for Mn up to this 
point are 

>for maximum power dissipation of 20 watts. 
> 

>Please let me know if the power of Mn is expected to be higher than 2 0 

watts . 

> 

>Herman 

This is an error in Paul ' s minutes . I think that the Mnemo module with DRAM is being 
confused with the Mnemo on a PCI card known as the PCl/Hestia card. Paul, can you correct 
the above to delete the reference to more RAM. 

The PCI/Hestia card will not have any DRAM (SIMMS) on it in any case. If this is unclear, 
please see me and we can publish the correction. 

-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
2 55 Caspian Dr. Sunnyvale, CA 94 08 9 
(408)734-8100, (408)734-8136 fax 


t be@m i c r ouni ty.com 
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From: tbr 

Sent: Saturday, March 18, 1995 1:15 AM 

To: 'woody (Jay Tomlinson)' 

Subject: euterpe module compile 

Follow Up Flag: Follow up 
Flag Status: Red 


Jay Tomlinson wrote (on Fri Mar 17): 


Tim, 

Dan has not yet released the new chips_prt generator, because he has to decide 
how to handle the 'flag body' parts (such as dgnd) which don't have a .gyg 
file. 

OK, thanks for the update. As far as I know, pattie has plenty to 
chew on right now. . . 

Tim 
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From: tbr 

Sent: Saturday, March 18, 1995 1 :24 AM 

To: 'Herman Chu' 

Cc: 'hchu@igineer'; 'pandora@igineer'; 'Paul Berry' 

Subject: Re: Notes from mtg 95-3-10 
Follow Up Flag: Follow up 

Flag Status: Red 


"Herman Chu" wrote (on Fri Mar 1 7): 


>The version mounted within Pandora can have more RAM and can produce more 
>heat. 


This is a new one to me! All the heat sink designs for Mn up to this point are 
for maximum power dissipation of 20 watts. 

Please let me know if the power of Mn is expected to be higher than 20 watts. 

We will have a good power number soon, but meanwhile 20W remains the 
target. I think the point that was being discussed at the meeting is 
that for the PC card we may well end up running the part more slowly 
at reduced power setting to drop the power well below the 20W. 

Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tim B. Robinson [tbr@igineer] 
Saturday, March 18, 1995 1:24 AM 
'Herman Chu' 

'hchu@igineer'; 'pandora@igineer'; 'Paul Berry' 
Re: Notes from mtg 95-3-10 


"Herman Chu" wrote (on Fri Mar 17) : 
> 

>The version mounted within Pandora can have more RAM and can produce more 

>heat . 

> 

This is a new one to me I All the heat sink designs for Mn up to this point are 
for maximum power dissipation of 20 watts. 

Please let me know if the power of Mn is expected to be higher than 20 watts. 

We will have a good power number soon, but meanwhile 20W remains the target. I think the 
point that was being discussed at the meeting is that for the PC card we may well end up 
running the part more slowly at reduced power setting to drop the power well below the 
20W. 


Tim 
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From: solo (John Campbell) 

Sent: Saturday, March 18, 1995 2:12 AM 

To: Tim B. Robinson' 

Cc: 'fwo (Fred Obermeier)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'Lisa Robinson'; 'Warren 
R. Ong'; 'solo@microunity.com'; Tom Laidig'; 'Dave Van't Hof 

Subject: Re: Daily Mismatches 
as Tim B. Robinson was saying 


.John Campbell wrote (on Fri Mar 17): 

. ..Has any action been taken already on this? I see no sign of a release 
. ..of this cell in /u/chip recently, and if it's nit released there, the 
. ..getbom will not pick it up in the snapshot. 

. ..Tim 


solo@echidna /u/chip/proteus/compass/layouts 8 % cvs status ioquadsofa.ly 


. File: ioquadsofa.ly Status: Up-to-date 

Version: 1.16 Thu Mar 16 10:42:38 1995 

RCS Version: 1.16 /p/cvsroot/proteus/compass/layouts/ioquadsofa.ly,v 
Sticky Tag: (none) 
Sticky Date: (none) 
Sticky Options: (none) 

. solo@echidna /u/chip/proteus/compass/layouts 9 % 

.OK, that was so many BOMs back I didn't look that far! Ths log says 
.this was in 5.1 089, and the snapshot is at 5.1 100, so it would appear 
.we are already up to date on this. 

.Tim 


looks uptodate since this afternoon. 


solo@nosferatu -/snap/compass 58 % cvs status /n/auspex/s4l/euterpe- 
snapshot/euterpe/proteus/compass/layouts/ioquadsofa.ly 


File: ioquadsofa.ly Status: Up-to-date 

Version: 1.16 Fri Mar 17 15:49:24 1995 

RCS Version: 1.16 /p/cvsroot/proteus/compass/layouts/ioquadsofa.ly ,v 
Sticky Tag: (none) 
Sticky Date: (none) 
Sticky Options: (none) 

solo@nosferatu ~/snap/compass 59 % 
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regards, EMail solo@microunity.com 

solo aJc.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Saturday, March 18, 1995 6:52 AM 
'Geert Rosseel' 

'billz (Bill Zuravleff)'; 'tbr (Tim B. Robinson)' 
Re: temporary fix .maybe 


Geert Rosseel writes: 
Hi, 

I commented out the pruned gates, out of the .pirn file and that got 
rid of the FATAL error. I still have to look at the result. I'll let 
you know if it worked . . . 

The nb-passl.dff file in /u/chip/euterpe . . . appears incomplete. 

I notice that 

/n/ghidra/s3/geert/euterpe/verilog/bsrc/gards/geert euterpe-iter .df f 
also looks incomplete, it contains only 

NB/BUF_64_NBACOUT/U3 7 XBBUFDH3 2S 
NB/BUF_64_NBACOUT/U36 XBBUFDH3 2S 
NB/BUF_64_NBACOUT/U35 XBBUFDH32S 
NB/BUF_64_NBACOUT/U34 XBBUFDH3 2S 
NB/BUF 64_NBACOUT/U33 XBBUFDH32S 
NB/BUF64NBACOUT/U32 XBBUFDH32S 
NB/BUF_64_NBACOUT/U3 XBBUFDH32S 
NB/BUF_64_NBACOUT/U2 XBBUFDH3 2 S 
NB/BUF_64_NBACOUT/U8 XBBUFDH24S 
NB/BUF_64_NBACOUT/U7 XBBUFDH24S 
NB/BUF_64_NBAC0UT/U5 XBBUFDH2 4 S 
NB/BUF_64_NBACOUT/U6 XBBUFDH16S 

While my local built NB-only version (pointing to the snapshot) contains: 

BUF_6 4_NBACOUT/U3 XBBUFDH3 2 S 
BUF_64_NBAC0UT/U2 XBBUFDH32S 
BUF_6 4_NBAC0UT /U6 3 XBBUFDH2 4 S 
BUF_64_NBACOUT/U62 XBBUFDH24S 
BUF_64_NBACOUT/U61 XBBUFDH24S 
BUF_64_NBACOUT/U6 0 XBBUFDH24S 
BUF_64_NBACOUT/U59 XBBUFDH24S 
BUF_64_NBACOUT/U58 XBBUFDH24S 
BUF_64_NBACOUT/U57 XBBUFDH24S 
BUF_64_NBACOUT/U56 XBBUFDH24S 
BUF_6 4JNBACOUT/ U5 5 XBBUFDH2 4 S 
BUF_64_NBACOUT/U54 XBBUFDH2 4 S 
BUF_64_NBACOUT/U53 XBBUFDH2 4 S 
BUF_64_NBACOUT/U52 XBBUFDH2 4 S 
BUF_64_NBACOUT/U51 XBBUFDH24S 
BUF_64_NBACOUT/U5 0 XBBUFDH2 4 S 
BUF_64_NBACOUT/U49 XBBUFDH24S 
BUF_64_NBACOUT/U48 XBBUFDH24S 
BUF_64_NBACOUT/U47 XBBUFDH24S 
BUF_64_NBACOUT/U46 XBBUFDH24S 
BUF_64_NBACOuT/U45 XBBUFDH24S 
BUF_64JNBACOUT/U44 XBBUFDH24S 
BUF_64_NBACOUT/U43 XBBUFDH24S 
BUF_64_NBACOUT/U42 XBBUFDH24S 
BUF_64_NBACOUT/U41 XBBUFDH24S 
BUF_64_NBACOUT/U40 XBBUFDH24S 
BUF_64_NBAC0UT/U39 XBBUFDH24S 
BUF_64_NBAC0UT/U3 8 XBBUFDH24S 
BUF_6 4 NBAC0UT / U3 7 XBBUFDH2 4 S 
BUF_6 4_NBAC0UT / U3 6 XBBUFDH2 4 S 
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BUF_6 4_NBACOUT / U3 5 XBBUFDH2 4 S 
BUF_64_NBACOUT/U34 XBBUFDH24S 
BUF_64_NBACOUT/U33 XBBUFDH24S 
BUF_64_NBACOUT/U32 XBBUFDH24S 
BUF_6 4_NBAC0UT/ U3 1 XBBUFDH2 4 S 
BUF_64_NBACOUT/U3 0 XBBUFDH24S 
BUF_6 4_NBACOUT / U2 S XBBUFDH2 4 S 
BUF_6 4_NBACOUT / U2 8 XBBUFDH2 4 S 
BUF_64_NBACOUT/U2 7 XBBUFDH24S 
BUF_6 4_NBAC0UT/ U2 6 XBBUFDH2 4 S 
BUF_64_NBACOUT/U25 XBBUFDH24S 
BUF_64_NBACOUT/U24 XBBUFDH24S 
BUF_64_NBACOUT/ U2 3 XBBUFDH2 4 S 
BUF_64_NBACOUT/U22 XBBUFDH24S 
BUF_6 4_NBAC0UT/ U2 1 XBBUFDH2 4 S 
BUF_6 4_NBAC0UT/ U2 0 XBBUFDH2 4 S 
BUF_64_NBACOUT/U19 XBBUFDH24S 
BUF_64_NBAC0UT/U18 XBBUFDH24S 
BUF_64_NBACOUT/U17 XBBUFDH 2 4 S 
BUF_64_NBACOUT/U16 XBBUFDH24S 
BUF_64_NBACOUT/U15 XBBUFDH24S 
BUF_64_NBACOUT/U14 XBBUFDH24S 
BUF_64_NBAC0UT/U13 XBBUFDH24S 
BUF_64_NBACOUT/U12 XBBUFDH24S 
BUF_64_NBAC0UT/U11 XBBUFDH24S 
BUF_64_NBACOUT/U10 XBBUFDH 2 4 S 
BUF_64_NBACOUT/U9 XBBUFDH24S 
BUF_64_NBACOUT/U8 XBBUFDH24S 
BUF_64_NBACOUT/U7 XBBUFDH24S 
BUF_64_NBACOUT/U5 XBBUFDH24S 
BUF_64_NBAC0UT/U4 XBBUFDH24S 
BUF_64_NBAC0UT/U1 XBBUFDH24S 
BUF_64_NBACOUT/U0 XBBUFDH24S 
BUF_64_NBACOUT/U6 XBBUFDH16S 


So, I think some data is missing, 
-hopper 
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From: geert (Geert Rosseel) 

Sent: Saturday, March 1 8, 1 995 1 2: 1 2 PM 

To: 'billz'i 'hopper'; 'tor' 

Subject: placement problem with nb at top-level 


Hi, 

I've run into a problem with nb placement at for the latest top-level. 
NB runs by itself in the snapshot, but when I include it at the top-level 
pim2pif gives me a FATAL error. I'll need soem help to figure out 
waht is going on (It claims thata cell is out of bounds > maxx ...) 

the data for nb itslef is in the proteus snapshot 

the top-level results are in /n/ghidra/s3/geert/euterpe/verilog/bsrc/gads/geert_euterpe* 


Thank's 
Geert 
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From: 


tbr 


Cc: 

Subject: 
Follow Up Flag: 
Flag Status: 


Sent: 


To: 


Saturday, March 18, 1995 12:13 PM 
'geert (Geert Rosseel)' 
'bills'; 'age'; 'hopper' 
placement problem with nb at top-level 
i: Follow up 
Red 


Geert Rosseel wrote 


(on Sat Mar 1 8): 


Hi, 


I've run into a problem with nb placement at for the latest top-level. 
NB runs by itself in the snapshot, but when I include it at the top-level 
pim2pif gives me a FATAL error. I'll need soem help to figure out 
waht is going on (It claims thata cell is out of bounds > maxx ...) 

I think it may be a generic exlax problem of some sort. I'm seeing 
similar trouble with mnemo. In that case there seem to be duplicate 
placements. I think alan understands what's going on in the mnemo case. 

the data for nb itslef is in the proteus snapshot 

the top-level results are in /n/ghidra/s3/geert/euterpe/verilog/bsrc/gads/geert_euterpe' K 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, March 18, 1995 12:13 PM 

'geert (Geert Rosseel)' 

'billz'; 'age'; 'hopper' 

placement problem with nb at top-level 


Geert Rosseel wrote (on Sat Mar 18) : 


Hi 


I've run into a problem with nb placement at for the latest top-level. 
NB runs by itself in the snapshot, but when I include it at the top-level 
pim2pif gives me a FATAL error. I'll need soem help to figure out 
waht is going on (It claims thata cell is out of bounds > maxx ...) 

I think it may be a generic exlax problem of some sort. I'm seeing similar trouble with 
mnemo. In that case there seem to be duplicate placements. I think alan understands 
what 1 s going on in the mnemo case . 

the data for nb itslef is in the proteus snapshot 
the top-level results are in 
/n/ghidra/ s3 /geert /euterpe/verilog/bsrc/gads/geert_euterpe* 


Tim 
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To: 
Cc: 


Sent: 


From: 


geert (Geert Rosseel) 

Saturday, March 18, 1995 12:29 PM 

'tbr' 


'age'; 'billz'; 'hopper* 


Subject: Re: placement problem with nb at top-level 

The problem seems to be in the datapath section of nb. The arrays and 
control section place, but the datapath does not ., 

NB creates 5 *.pif files, 4 of them work at the top-level but 
the last one does not. 

For who's interested : the 5 pif files are geert_euterpe-iter.pif.14 to 18. 
pif.18 is empty and that is the one that should contain the datapath part. 


Geert 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Saturday, March 18, 1995 12:31 PM 
'geert (Geert Rosseel)' 
'age'; 'billz'; 'hopper* 

Re: placement problem with nb at top-level 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Mar 1 8): 

The problem seems to be in the datapath section of nb. The arrays and 
control section place, but the datapath does not ., 

NB creates 5 *.pif files, 4 of them work at the top-level but 
the last one does not. 

For who's interested : the 5 pif files are geert_euterpe-iter.pif.14 to 18. 
pif. 1 8 is empty and that is the one that should contain the datapath part. 

OK, it's not releated to the mnemo probel, which alan has figure out 
(something out of date bacuase of a failed release). 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, March 18, 1995 12:31 PM 

'geert (Geert Rosseel)' 

'age'; 'billz'; 'hopper' 

Re: placement problem with nb at top-level 


Geert Rosseel wrote (on Sat Mar 18) : 

The problem seems to be in the datapath section of nb. The arrays and 
control section place, but the datapath does not . , 

NB creates 5 * .pif files, 4 of them work at the top-level but 
the last one does not. 

For who's interested : the 5 pif files are geert_euterpe-iter ,pif . 14 to 18. 
pif .18 is empty and that is the one that should contain the datapath part. 

OK, it's not releated to the mnemo probel, which alan has figure out (something out of 
date bacuase of a failed release) . 


Tim 
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From: brianl (Brian Lee) 

Sent: Saturday, March 1 8, 1 995 1 : 54 PM 

To: Tim B. Robinson' 

Cc: 'age (Alan Corry)' 

Subject: Re: New problem 

Tim B. Robinson writes: 


jl picked up your new top leel BOM, then re-tried dramctrl. Now it 

jfails with a missing pdl file: 

I 

I 

|/n/auspex/sl5/tbr/mnemo/tools/bin/pdIcat: ealdfl6s4x4a.pdl not found 

in /n/auspex/sl 5/tbr/mnemo/clockbias:/n/auspex/sl 5/tbr/mn emo/gards/subb locks :/n/auspex/sl 5/tbr/mnemo/gards/dcell:/n/ausi 
|/n/auspex/sl5/tbr/mnemo/tools/btn/pdlcat: ealnf24s6x4a.pdl not found 

in /n/auspex/s 1 5/tbr/mnemo/clockbias:/n/auspex/s 1 5/tbr/mnemo/gards/subblocks:/n/auspex/s 1 5/tbr/mnemo/gards/dcell:/n/ausi 

|gmake[2]: *** [gards/dramctrl-pass 1 macros. pdl] Error 2 

|gmake[2]: Leaving directory ^/N/auspexe/slS/tbr/mnemo/verilog/src/dramctrr 

jgmakefl]: *** [dramctrl-base.short.nets] Error 1 

jgmakeflj: Leaving directory '/N/auspexe/sIS/tbr/mnemo/verilog/src/dramctrl' 
jgmake: *** [dramctrlgards] Error 1 


|Brian, what's the status of the snapshot rebuild? I'm working on 
jmnemo, but am pointing to the euterpe snapshot proteus. I have a 
jsuspicion that this may be a new cell for which we may not yet have a 
I layout at all. 

The snapshot build died earlier this morning. I've released a fix and have 
restarted the getbom/.checkoutrc process on ghidra. 

The layouts for these ea cells do exist in the snapshot, but the 
exlax/elibsrc/Makefile did not specify them at the time the snspshot 
pdls were last built. When the current build finishes, hopefully 
sometime late tonight, the pdls should be there. Until then, /u/chip 
should be consistent 


Brian L. 
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From: dickson (Richard Dickson) 

Sent: Saturday, March 18, 1995 1:59 PM 

To: 'geerf 

Subject: rich_euterpegards 


geert, 


sorry to be a pain but the new makefile stuf is still not working for me. see 
dickson/euterpe/verilog/bsrc/aaa its failing in garout . i dont see anything obvious ??? 

dickson 
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From: lisar (Lisa Robinson) 
Sent: Saturday, March 18, 1995 2:08 PM 
To: 'mws'; 'billz'; 'dickson'; 'woody'; 'tbf 
Subject: Dumps to look at ... 

I have tried to re-create the dcacheeasy and dcacheharder failures in 
verilog but have been unsuccessful. In both cases the default verilog 
environment produced fabs. 

I replaced the model of a dlatchq and re-ran in both 
cases the tests went to x very early. 

Could someone please look at the dump of dcacheeasy or dcacheharder on 
staypuft /s3/br/euterpe/verilog/bsrc. 


Also there is a dump of an stgen_rl331 1_0 run in the same directory. 

Here the test is going to bad very early on I think as a result of a 

read from cerberus octlet 10. Again I was using the local dlatchq model. 

This is what is expected ... 

006 1 c608c 11 d43 0 1 006 1 c608c 1 1 d430 1 

But this is what I get ... 

c3 8c 1 1 823 a870200c3 8c 1 1 823a870200 

Now if I shifted that right by 9 doesn't it almost match? 

0061c608clld4381 

Lisa R. 
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From: 


tbr 


Sent: 

To: 

Cc: 


Saturday, March 18, 1995 2:11 PM 


Subject: 


'brianl (Brian Lee)' 
'age (Alan Corry)' 
Re: New problem 


Follow Up Flag: Follow up 
Flag Status: Red 

Brian Lee wrote (on Sat Mar 1 8): 

Tim B. Robinson writes: 

I 

I 

|I picked up your new top leel BOM, then re-tried dramctrl. Now it 
jfails with a missing pdl file: 


j/n/auspex/slS/tbr/mnemo/tools/bin/pdlcat: ealdf 1 6s4x4a.pdl not found 
in /n/auspex/s 1 5/tbr/mnemo/clockbias:/n/auspex/s 1 5/tbr/mnemo/gards/subblocks:/n/auspex/s 1 5/tbr/mnemo/gards/dceIl:/n/ausj 

|/n/auspex/sl5/tbr/mnemo/tools/bin/pdlcat: ealnf24s6x4a.pdl not found 
in /n/auspex/s 1 5/tbr/mnemo/clockbias:/n/auspex/s 1 5/tbr/mnemo/gards/subblocks :/n/auspex/s 1 5/tbr/mnemo/gards/dcell:/n/ausi 

jgmake[2]: *** [gards/dram Ctrl -pass 1 macros .pdl] Error 2 

|gmake[2]: Leaving directory > /N/auspex6/sl5/tbr/mnemo/verilog/src/dramctrr 

jgmakefl]: *** [dramctrl-base.short.nets] Error 1 

jgmakefl]: Leaving directory , /N/auspex6/sl5/tbr/mnemo/verilog/src/dramctrl' 
jgmake: *** [dramctrlgards] Error 1 

I 

I 

|Brian, what's the status of the snapshot rebuild? I'm working on 
jmnemo, but am pointing to the euterpe snapshot proteus. I have a 
jsuspicion that this may be a new cell for which we may not yet have a 
I layout at all. 

The snapshot build died earlier this morning. I've released a fix and have 
restarted the getbom/.checkoutrc process on ghidra. 

The layouts for these ea cells do exist in the snapshot, but the 
exlax/elibsrc/Makefilc did not specify them at the time the snspshot 
pdls were last built. When the current build finishes, hopefully 
sometime late tonight, the pdls should be there. Until then, /u/chip 
should be consistent. 

Thanks, I'll look for them later tonight . . . 


Tim 
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From: pmayer (Patricia Mayer) 

Sent: Saturday, March 18, 1995 4:58 PM 

To: 'tbe' 

Cc: 'pmayer 1 ; 'tbr' 

Subject: Euterpe Memory 

> From craig Thu Mar 16 14:34:44 1995 

> Subject: Re: Euterpe module 

> 

> > A potential requirement for 16MB of SDRAM in the Euterpe brick has 

> > come up. 

> > 

> > This can be acheived using 8 4Mx4 parts which Euterpe supports, 

> > but the current PCB design does not It may not be practical to have 

> > a single PCB layout support 2 lMxl6, 4 2Mx8, or 8 4Mx4 parts, but 

> > clearly we could have two different PCBs in that case. The most 

> > important thing is to be sure we have physical space to accommodate 8 

> > SDRAM components and that we can cool them in the module. 
>> 

> > Tom, pattie, can you look at these issues to make sure the current 

> > form factor can accommodate this option if it shoud become a hard 

> > requirement? The 4Mx4 part is in the same package as the 2Mx8. 

> > 

>>Tim 

> 

> Can the pin interface admit the possibility of using 8 2Mx8 parts 

> for a 16 MB memory? This requires select pins and additional 

> capacitance on the data pins, but would permit us to stock 

> fewer SDRAM part types. It also presumes that 2Mx8 parts are 

> no less available than 4Mx4 parts. 
> 

> Craig 

> 

Tom, 

Do you know what this would really look like? 

Right now we have 4 surrounding the 2 in the center, 
What would this look like? Basicly another set? Where are 
the connections coming from? 

Can we mount a set of 4 on the other side? A piggy back board mount? 

>From the scketches I've played with I don't see a fit, but the board 
size has grown to 6X8 inches? 

I'd like to get a better understanding of the dimensions and connections, 
then I can better understand the issue. 

Perhaps you can stop by Monday morning? 

Thanks 
-Pattie 
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From: tbr 

Sent: Saturday, March 18, 1995 5:09 PM 

To: 'pmayer (Patricia Mayer)' 

Cc: 'pmayer'; 'woody'; 'toe' 

Subject: Euterpe Memory 
Follow Up Flag: Follow up 

Flag Status: Red 


Patricia Mayer wrote (on Sat Mar 1 8): 


> From craig Thu Mar 16 14:34:44 1995 

> Subject: Re: Euterpe module 

> 

> > A potential requirement for 16MB of SDRAM in the Euterpe brick has 

> > come up. 

>> 

> > This can be acheived using 8 4Mx4 parts which Euterpe supports, 

> > but the current PCB design does not. It may not be practical to have 

> > a single PCB layout support 2 1Mx16, 4 2Mx8, or 8 4Mx4 parts, but 

> > clearly we could have two different PCBs in that case. The most 

> > important thing is to be sure we have physical space to accommodate 8 

> > SDRAM components and that we can cool them in the module. 
>> 

> > Tom, pattie, can you look at these issues to make sure the current 

> > form factor can accommodate this option if it shoud become a hard 

> > requirement? The 4Mx4 part is in the same package as the 2Mx8. 

> > 

>>Tim 

> 

> Can the pin interface admit the possibility of using 8 2Mx8 parts 

> for a 16 MB memory? This requires select pins and additional 

> capacitance on the data pins, but would permit us to stock 

> fewer SDRAM part types. It also presumes that 2Mx8 parts are 

> no less available than 4Mx4 parts. 
> 

> Craig 


Tom, 

Do you know what this would really look like? 

Right now we have 4 surrounding the 2 in the center, 
What would this look like? Basic ly another set? Where are 
the connections coming from? 

Imagine how hou have the 2 x8 parts straddling each of the !Mxl6 
parts. In the configuration with 8 by 4 parts you would in effect 
need to straddle each 2Mx8 with 2 lMx4 parts. 

As I mentioned in the earlier mail, it's probably not realistic 
to amke a single board that would support all 3 configurations, 
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or the main issue is how we would fit a total of 8 parts in there. 

Can we mount a set of 4 on the other side? A piggy back board mount? 

Mouss has suggested we put all the ram on a daughter card, so we can 
have different plug in modules. 1 don't like that idea because it 
adds complexity, and I don't think doing two euterpe boards for the 2 
configurations would be any more work than doing 1 pluss a seletciotn 
of dsaughter cards. 

>From the scketches I've played with I don't see a fit, but the board 
size has grown to 6X8 inches? 

I'd like to get a better understanding of the dimensions and connections, 
then I can better understand the issue. 

Perhaps you can stop by Monday morning? 

As far as the connectivity goes, jay would be best equipped to discuss 
that. 

Tim 
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From: Tom Eich [tbe@microunity.com] 
Sent: Saturday, March 1 8, 1995 5:35 PM 
To: 'pmayer (Patricia Mayer)' 
Cc: tbr* 

Subject: Re: Euterpe Memory 

» From craig Thu Mar 16 14:34:44 1995 
» Subject: Re: Euterpe module 

» 

» > A potential requirement for 16MB of SDRAM in the Euterpe brick has 
» > come up. 

» > 

» > This can be acheived using 8 4Mx4 parts which Euterpe supports, 
» > but the current PCB design does not. It may not be practical to have 
» > a single PCB layout support 2 1Mx16, 4 2Mx8, or 8 4Mx4 parts, but 
» > clearly we could have two different PCBs in that case. The most 
» > important thing is to be sure we have physical space to accommodate 8 
» > SDRAM components and that we can cool them in the module. 
» > 

» > Tom, pattie, can you look at these issues to make sure the current 
» > form factor can accommodate this option if it shoud become a hard 
» > requirement? The 4Mx4 part is in the same package as the 2Mx8. 

»> 
»> Tim 

» 

» Can the pin interface admit the possibility of using 8 2Mx8 parts 

» for a 16 MB memory? This requires select pins and additional 

» capacitance on the data pins, but would permit us to stock 

» fewer SDRAM part types. It also presumes that 2Mx8 parts are 

» no less available than 4Mx4 parts. 

» 

» Craig 

» 
> 

>Tom, 

> 

>Do you know what this would really look like? 

> 

>Right now we have 4 surrounding the 2 in the center, 
>What would this look like? Basicly another set? Where are 
>the connections coming from? 

Still from Euterpe, so I assumed it would just mean more SDRAMs above Euterpe. 

> 

>Can we mount a set of 4 on the other side? A piggy back board mount? 

> 

»From the scketches I've played with I don't see a fit, but the board 
>size has grown to 6X8 inches? 

Yes, the board is now larger, about 6" high by 7" wide. 

>I'd like to get a better understanding of the dimensions and connections, 
>then I can better understand the issue. 

> 
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>Perhaps you can stop by Monday morning? 


I'll be seeing you then I expect on the the Hestia Pro/E to Allegro translation. 

>Thanks 
>-Pattie 

If not Monday morning, then afternoon. 
-Tom 


Tom Eich tbe@microunity.com 
MicroUnity Systems Engineering, Inc.i 
255 Caspian Dr. Sunnyvale, CA 94089 | 
(408)734-8100, (408)734-8136 fax | 
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From: Tom Eich [tbe@microunity.com] 
Sent: Saturday, March 18, 1995 5:40 PM 
To: 'tbr (Tim B. Robinson)' 
Cc: 'pmayer'; 'woody' 
Subject: Re: Euterpe Memory 

Tim Robinson wrote: 

>Patricia Mayer wrote (on Sat Mar 1 8): 

> 

>snip< 

> 

> Tom, 

> 

> Do you know what this would really look like? 

> 

> Right now we have 4 surrounding the 2 in the center, 

> What would this look like? Basicly another set? Where are 

> the connections coming from? 

> 

>Imagine how hou have the 2 x8 parts straddling each of the 1Mx16 
>parts. In the configuration with 8 by 4 parts you would in effect 
>need to straddle each 2Mx8 with 2 1Mx4 parts. 

> 

>As I mentioned in the earlier mail, it's probably not realistic 
>to amke a single board that would support all 3 configurations, 
>or the main issue is how we would fit a total of 8 parts in there. 

> 

> Can we mount a set of 4 on the other side? A piggy back board mount? 

> 

>Mouss has suggested we put all the ram on a daughter card, so we can 
>have different plug in modules. I don't like that idea because it 
>adds complexity, and I don't think doing two euterpe boards for the 2 
Configurations would be any more work than doing 1 pluss a seletciotn 
>of dsaughter cards. 


What kind of daughterboard connector would we need in order to deal with 
the sub ns rise time memory signals? I actually think it is _more_ work, 
and more cost in manufacturing to have several daughtercards on top of the 
Euterpe pcb. 

> >From the scketches I've played with I don't see a fit, but the board 

> size has grown to 6X8 inches? 

> I'd like to get a better understanding of the dimensions and connections, 

> then I can better understand the issue, 

> 

> Perhaps you can stop by Monday morning? 

> 

>As far as the connectivity goes, jay would be best equipped to discuss 
>that. 

> 

>Tim 

If Jay can get with Pattie Monday, I'll then have time to finish off the 
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Hestia transfer. 
-Tom 


Tom Eich j tbe@microunity.com 

MicroUnity Systems Engineering, Inc.| 
255 Caspian Dr. Sunnyvale, CA 94089 j 
(408)734-8100, (408)734-8136 fax | 
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From: tbr 

Sent: Saturday, March 18, 1995 6:58 PM 

To: Tom Eich' 

Cc: 'pmayer*; 'woody' 

Subject: Re: Euterpe Memory 

Follow Up Flag: Follow up 

Flag Status: Red 


Tom Eich wrote (on Sat Mar 18): 

> 

>Mouss has suggested we put all the ram on a daughter card, so we can 
>have different plug in modules. 1 don't like that idea because it 
>adds complexity, and I don't think doing two euterpe boards for the 2 
Configurations would be any more work than doing 1 pluss a seletciotn 
>of dsaughter cards. 
> 

What kind of daughterboard connector would we need in order to deal with 
the sub ns rise time memory signals? 1 actually think it is _more_ work, 
and more cost in manufacturing to have several daughtercards on top of the 
Euterpe pcb. 

I agree. The only reason to do it would be to permit field 
upgradability. That's not an issue in pandora because we may well not 
even population the SDRAM since we have main memory on the Mnemo 
modules. 

If the Euterpe brick gets used in a different system we can turn the 
board as necessary to provide the application specific options required. 

Tim 
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From: dickson (Richard Dickson) 

Sent: Saturday, March 18, 1995 11:24 PM 

To: 'geert' 

Subject: rich_euterpe 


geert , 

it run to completion now but gates get pruned 111 


dickson 
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From: 


tbr 


Sent: 

To: 

Cc: 


Subject: 


Sunday, March 19, 1995 12:38 PM 

•geert' 

'woody' 

hcO 


Follow Up Flag: Follow up 
Flag Status: Red 


I have a new version, 100% ahnd placed. I'm not sure if it's better. 
It took 7 iterations to converge and is a couple of hundred atoms 
nigger than the previous version. 

However, it is very porus in M4 in the lower section, so it may well 
help. I'd like to do a bit more work on it before I give up. 

If you want to take a look at it it's in 
~tbr/euterpe/verilog/src/hc/hcO-iter. 


Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, March 19, 1995 12:38 PM 

'geert' 

'woody' 

hcO 


I have a new version, 10 0% ahnd placed. I'm not sure if it's better. 

It took 7 iterations to converge and is a couple of hundred atoms nigger than the previous 
version. 

However, it is very porus in M4 in the lower section, so it may well help. I'd like to do 
a bit more work on it before I give up. 

If you want to take a look at it it's in ~tbr/euterpe/verilog/src/hc/hcO-iter . 


Tim 
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Sent: 
To: 

Subject: 


From: 


tbr 

Sunday, March 19, 1995 12:41 PM 
'brianl (Brian Lee)' 
Re: snapshot 


Follow Up Flag: Follow up 
Flag Status: Red 

Brian Lee wrote (on Sun Mar 19): 

It's still doing the capacitance simulations. Unfortunately, there 
was another reset yesterday. After I unstuck the getbom, it never 
started the .checkoutrc. When I checked later, all my processes 
were gone. Not knowing what happened or where it left off, I decided 
to be safe and start from another getbom. 

There are about 100 more capacitance simulations. After that it should 
finish relatively quickly. 

OK, not to worry, I have euterpe stuff to look at. 


Tim 
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From: geert (Geert Rosseel) 

Sent: Sunday, March 19, 1995 12:54 PM 

To: 'billz'; 'dickson'; 'hopper'; 'mws'; 'tbr'; 'vo'; 'wampler'; 'woody' 

Subject: Latest top-level 

Hi, 

The latest top-level route finished : 

linesearch : 3000 disconnect 
maze : 570 disconnect 

Remember that thi sis the latest routing strategy, which routes the long nets 
first and results in more disconnects (but more localized) 


-> Rich's section fully routes 

-> GT still has considearble number of disconnects 

-> There is a problem with the load data into the xlu that 

needs to be resolved with routing order. I will work on that. 
-> 20-30 unroutes in hcl 

-> I must have picked up a different hcO. This one full routes 

but does not meet timing in the snapshot. Is that the fully 

mincut version ? 
-> at is off-set by 1 row compared to nb, sr and cc 
-> still some disconnects in the datapath around rg 

Top-level data is going to be in /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards2 . 

I will work on the nb-xlu routing problem. I think somebody should took at 
gt at the top-level. 

Geert 
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From: tbr 

Sent: Sunday, March 1 9, 1 995 1 :07 PM 

To: 'geert (Geert Rosseel)' 

Cc: 'billz'; 'dickson'; 'hopper'; 'mws'; Vo'; 'wampler*; 'woody* 

Subject: Latest top-level 
Follow Up Flag: Follow up 

Flag Status: Red 


Geert Rosseel wrote (on Sun Mar 19): 


Hi, 

The latest top-level route finished : 

linesearch : 3000 disconnect 
maze : 570 disconnect 

Remember that thi sis the latest routing strategy, which routes the long nets 
first and results in more disconnects (but more localized) 


-> Rich's section fully routes 

-> GT still has considearble number of disconnects 

Is this now with the version with single ended interconnect in the snake? 

-> There is a problem with the load data into the xlu that 

needs to be resolved with routing order. I will work on that. 
-> 20-30 unroutes in hcl 

-> I must have picked up a different hcO. This one full routes 
but does not meet timing in the snapshot. Is that the fully 
m incut version ? 

I have not checked in what I've been doing. The version I picked up 
from what I thought was the latest bom certainly looked all m incut, 
at least he data path was scattered all over, 

-> at is off-set by 1 row compared to nb, sr and cc 
-> still some disconnects in the datapath around rg 

Top-level data is going to be in /n/ghidra/s3/geert/euterpe/veriIog/bsrc/gards2 . 

I will work on the nb-xlu routing problem. I think somebody should look at 
gtatthe top-level. 

I'll take a look at it. I think there is still some scope to reduce 
horizontal routing by moving the address decoding part of the control 
to the left some. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, March 19, 1995 1:08 PM 

'geert (Geert Rosseel)' 

'billz'; 'dickson'; 'hopper'; 'mws'; Vo'; 'wampler'; 'woody' 
Latest top-level 


Geert Rosseel wrote (on Sun Mar 19) : 


Hi, 


The latest top-level route finished : 


linesearch 
maze 


3 000 disconnect 
570 disconnect 


Remember that thi sis the latest routing strategy , which routes the long nets 
first and results in more disconnects (but more localized) 


-> Rich's section fully routes 

-> GT still has considearble number of disconnects 

Is this now with the version with single ended interconnect in the snake? 

-> There is a problem with the load data into the xlu that 

needs to be resolved with routing order. I will work on that. 
-> 20-3 0 unroutes in hcl 

- > I must have picked up a different hcO . This one full routes 
but does not meet timing in the snapshot. Is that the fully 
mincut version ? 

I have not checked in what I've been doing. The version I picked up from what I thought 
was the latest bom certainly looked all mincut, at least he data path was scattered all 
over. 

-> at is off -set by 1 row compared to nb, sr and cc 
-> still some disconnects in the datapath around rg 

Top-level data is going to be in 
/n/ghidra/s3 /geert /euterpe/verilog/bsrc/gards2 . 

I will work on the nb-xlu routing problem. I think somebody should look at 
gt at the top-level. 

I'll take a look at it . I think there is still some scope to reduce horizontal routing by 
moving the address decoding part of the control to the left some. 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Sunday, March 19, 1995 2:29 PM 

To: 'dickson' 

Cc: 'tbr 1 

Subject: knobharder 


Rich, 

I have always run knobharder on the zycad where the model for dlatchq is the same 
for verilog. 

I have done a run in verilog where I replaced the dlatchq model with the same 
model as is used on the Ikos. The test failed in a similar way to the stgen run. 

The dump is on nosferatu /s5/euterpe/verilog/bsrc. 
Lisa R. 
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From: geert (Geert Rosseel) 

Sent: Sunday, March 19, 1995 2:53 PM 

To: 'billz'; 'dickson'; 'hopper'; 'mws'; 'tbr*; Vo'; 'wampler'; 'woody' 
Subject: More on top-level euterpe 


Hi, 

There was a small problem with the route in the latest top-level. The 
early.net file was empty anf therefore, no early nets were routed 
in this route. I fixed the problem and run it again. I believe 
that this will fix the xlu load data problem. 

Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Monday, March 20, 1995 9:29 AM 
'Mark Hofmann' 

Vanthof (Dave Van't Hof)'; 'lisar (Lisa Robinson)'; 'tbr (Tim B. Robinson)'; 'vo (Tom Vo)'; 'geert 
(Geert Rosseel)' 

Re: LVS of small euterpe finished? 


Mark Hofmann writes; 


>Hi Dave, 
> 

> I noticed that the LVS of the small euterpe finished. I was just 
curious- 

>how does it look? 
> 

> -thanks, 

> hopper 


The lvs finished yesterday about 8:30 pm (took 3 days 2 hours to run). 
There are mismatches: 


There are NO shorts between labeled nodes, However, there still could be shorts between 
unlabeled nodes. I had hoped for a bit better result, but these mismatches could still be 
because it's not a fullchip. 

I'll look at the output this morning. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

2 55 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 # include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 


> 


NUMBER OF UN- MATCHED SCHEMATICS DEVICES 

NUMBER OF UN- MATCHED LAYOUT DEVICES 

NUMBER OF MATCHED SCHEMATICS DEVICES 

NUMBER OF MATCHED LAYOUT DEVICES 


4423 
4204 
888836 
888836 


Thanks , 
Dave 
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From: woody (Jay Tomlinson) 

Sent: Monday, March 20, 1 995 1 0:30 AM 

To: 'mws (Mark Semmelmeyer)' 

Cc: 'billz'; 'dickson'; 'lisar'; 'mws'; 'tbr' 

Subject: Re: Dumps to look at ... / dcacheeasy 

Mark Semmelmeyer wrote (on Sat Mar 18): 

> From lisar Sat Mar 18 1 1:07:53 1995 

> I have tried to re-create the dcacheeasy and dcacheharder failures in 

> verilog but have been unsuccessful. In both cases the default verilog 

> environment produced fabs. 

> 

> I replaced the model of a dlatchq and re-ran in both 

> cases the tests went to x very early. 

> 

> Could someone please look at the dump of dcacheeasy or dcacheharder on 

> staypuft /s3/br/euterpe/verilog/bsrc. 

I looked at dcacheeasy and traced evenModeUR X back through the preempt 
logic to NB load data return on NBweDXl X at 357690 to HClprb[] at 356020 
to dhchdis_abm[l :0] going from 3 to 0 at 3551 76 (I am guessing now 
because I don't understand the microarchitecture in this area 
and the dump only has euterpe and uu in it). The cpudinl [] bus into 
HC1 is permanently X with the ivalidl always active. The phiIl_A2P 
into ioratel is permanently X. Maybe someone with more IO/HC 
experience can take over now. 

I will look at this and see if I can see anything from the information dumped, 
woody 
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Subject: 


From: 


Sent: 
To: 

Cc: 


vanthof (vant) 

Monday, March 20, 1995 10:31 AM 

Vo (Tom Vo)'; 'geert (Geert Rosseel)' 

'vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)' 

euterpe Ivs results 


Hi, 


The euterpe lvs results are a bit confusing, as it appears most of the bizarrenes is 
from the schematics. The output of the lvs run is in: 


/u/ vanthof / compass /mobi /euterpe/ tapeout /euterpe . compare /euterpe . lvs 

There appears to be some confusion about vdde supplies in the schematics for the 
temperature sensor and the pll. Well, first glance at the output seems to indicate this. 
For the tsensa layouts, the signal VDDETS in the schematic seems to want to be VDDE, and 
in the pll, the VDDEPO seems to want to be VDDE. 

Is there some new power supply mapping that must go on? 
I'll keep looking. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc. 

2 55 Caspian Way, Sunnyvale, CA (408) 73 4-8100 X2 76 # include <std_disclaim. h> Don't blame 
me, I didn't vote for him! 


Dave 


Exhibit C12 


Page 383 of 643 


From: woody (Jay Tomlinson) 

Sent: Monday, March 20, 1 995 1 0:45 AM 

To: 'lisar' 

Cc: 'billz'; 'dickson'; 'mws'; 'tbr* 

Subject: Re: Dumps to look at ... / dcacheeasy 

Mark Semmelmeyer wrote (on Sat Mar 18): 

> From lisar Sat Mar 18 1 1 :07:53 1995 

> I have tried to re-create the dcacheeasy and dcacheharder failures in 

> verilog but have been unsuccessful. In both cases the default verilog 

> environment produced fabs. 

> 

> I replaced the model of a dlatchq and re-ran in both 

> cases the tests went to x very early, 

> 

> Could someone please look at the dump of dcacheeasy or dcacheharder on 

> staypuft /s3/br/euterpe/verilog/bsrc. 

I looked at dcacheeasy and traced evenModeUR X back through the preempt 
logic to NB load data return on NBweDXl X at 357690 to HClprb[] at 356020 
to dhchdis_abm[l:0] going from 3 to 0 at 355176 (I am guessing now 
because I don't understand the microarchitecture in this area 
and the dump only has euterpe and uu in it). The cpudinl [] bus into 
HC1 is permanently X with the i valid 1 always active. The phi!l_A2P 
into ioratel is permanently X. Maybe someone with more IO/HC 
experience can take over now. 

It looks to me like the problem is that hermes channel 1 is enable, but there 
isn't a device there, because clkinl, dinl are both *z'. 

woody 
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From: vanthof (vant) 

Sent: Monday, March 20, 1995 10:59 AM 

To: 'Geert Rosseel' 

Cc: Vanthof (Dave Van't Hof)'; 'vo (Tom Vo)'; 'hopper (Mark Hofmann)' 

Subject: Re: euterpe Ivs results 


Geert Rosseel writes: 
> 

>This layout probably has the bad iobyte, with the misiing ioquadcontrol . 

>That should account for a number of the mismatches. 

> 

> Geert 


Yes, you are correct. I never did kill that run. Thank you for reminding me. 
I'll start up another one this morning. 

Would the missing ioquadcontrol also account for the bizareness with VDDEPO, VDDEP1, and 
VDDTS? 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 # include <std_disclaim. h> Don't blame 
me, I didn't vote for him! 
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From: lisar (Lisa Robinson) 

Sent: Monday, March 20, 1995 11:03 AM 

To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr*; 'woody' 

Cc: 'doi'; 'geert' 

Subject: test status 

BOM 258 running on Zycad 
BOM 258 running on IKOS 

New business 

stgen_jl 33 1 1J) (dram) 253 - Runs okay in verilog but not on Ikos replaced dlatchq model then 
cerberus failed see knobharder. dump on staypuft /s3/tbr/euterpe .. 

stgen_r22478_0 (hermes) 253+ - bad trace on aphrodite /s3 17395.18080 


knobharder 258 - bad dump on nosferatu /s5/euterpe .. Note local dlatchq model 

dcacheeasy_0 257 bad 

dcacheharder_0 257 - X trace on rhodan /s3 18395.11180 

nb_combo 258 - X nosferatu /s2 19395.15050 

Next group on rhodan /s3 19395.13268 

cache__U 258 -X 

bgate_U 258 - Understood (nbreject) 

barrel JU 258 - X now but Showed same failure as stgen_rl33 1 1 on 253 

interruptJJ 258 

gtlb_miss_U 258 - Showed same failure as stgen_r 1 33 1 1 on 253 

synchJU 258 
instrJJ 258 
exceptionU 258 
tlb_U 258 

dcacheexcept 244 - dcache tag exception 2 was not recieved when expected 
exception bit set in tag but not in GTLB - rhodan /s3 6395.2961 
trying to re-create with dcacheharder5 
258 - reunning now rhodan /s3 20395.15144 

synchj 253 - X rhodan /s3 10395.25253 cache„debug vldUV_debug 14395.326 

atomic conflict l 250 - Understood 

xlu_field_4_l 250 - X (Ran for much longer) rhodan /s3 1 1395 .5887 Same as cache JJ 


dcache j»erf_stl t_l 250 - Same as stgen_rl 33 1 1 
dcache_perf _ldst5t_l 25 0 - Same as stgen_r 1 3311 

dcache_conflictJ 250 Thread 3, Reg 1, Param Entry 2 Expected 1020304050607 Got ffffdfffififiTff - trace on 
rhodan /s3 11395.6701 

instr_l 25 1 - Same as cacheU 

insn 1 251 - Same as cacheJJ 

tlb_l 250 - X rhodan /s3 1 1395.6933 
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Old Business - Need to reun and if necessary redump these 


interleave^ 


247 - X and doesn't enable hermes (comment in log says otherwise?) nosferatu /s2 1 1395.15228 


unix_l 


250 - Looks like the test resets the machine 


cerbarbeasy_0 


Lisa R to run again as verilog run is well behaved 


Performance Failures (Test ran to completion but failed performance measure) 

dcache_perf_ld It 1 Expected difference between the cached and non-cached access = 4600-5050 cycles 

Actually took 3650 fewer cycles rhodan /s3 24295.8260 
icache_perf_lt_l Expected difference between the cached and non-cached access - 46000-50600 cycles 

Actually took 123800 fewer cycles rhodan /s3 26295.14314 
icache_perf_5t_l Expected difference between the cached and non-cached access = 58000-63800 cycles 

Actually took 1 17120 (!) fewer cycles rhodan /s3 6395.3461 
nb_l Actual accept time = 160: 186 Expected accept time = 150:180 rhodan /s3 28295.4379 

nb_slow Actual accept time = 160:186 Expected accept time = 150:180 rhodan /s3 28295.4379 

nbjiermes Actual Completion Time = 530 : 642 Expected Completion Time = 250 : 300 aphrodite /s3 

17395.19127 

Have not yet been run: 


hermes_load_0 

hermesconflictl 258 - running now 
ruptpintest_0 - Need to build a "custom" simulator 
interleave_U 

Cannot yet be run: 


nulltest 
XLU tests 


xlu_rotate_l_l 

xlu_rotate_2_l 

xlu_expand_l_l 

xlu_compress_l_l 

xlu_extract_l_l 

xlu_field_l_l 

xlujield_2_l 

xlu_fleld_3_l 

x lu_copy swap_ 1 _ 1 

xlu_copyswap_2_ 1 

xlu_copyswap_3_ 1 

xlu_copyswap_4_l 

xlu_shufflemux_ 1 _ 1 

xluselectll 

Not yet implemented: 


brcolltest_0 

brcrosstestO 

brimmlongtestO 

expriotestO 

canceltest_0 

hermtotest_0 

cerbtotest_0 

hermerrtest_0 

eventregtest_0 
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exintbashtest_0 

cerberrtest 

cerberror_0 

testerinit_0 

memmap 0 

nbbashtestj) 

cerbarbtests 

hcplltests 

addr_mad_void 
addr_map_mc 
addr_map_cerb 
addr_map_h ermes 

node-boot 
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From: pmayer (Patricia Mayer) 

Sent: Monday, March 20, 1 995 1 : 1 1 PM 

To: 'phililp'; 'tbr' 

Cc: 'pmayer'; 'woody'; 'tbe' 

Subject: Re: Euterpe Memory 

Talked to Jay and understand the phsical layout needs but I 
still don't know anything about the parts. 

Do we have anything on this - Philip? 

-Pattie 

> From tbr Sat Mar 1 8 14:09:04 1995 

> Date: Sat, 18 Mar 1995 14:09:02 -0800 

> From: tbr (Tim B. Robinson) 

> To: pmayer (Patricia Mayer) 

> Cc: pmayer, woody, tbe 

> Subject: Euterpe Memory 

> Content-Length: 2547 
> 

> 

> Patricia Mayer wrote (on Sat Mar 1 8): 

> 
> 

> > From craig Thu Mar 16 14:34:44 1995 

> > Subject: Re: Euterpe module 

> > 

> > > A potential requirement for 16MB of SDRAM in the Euterpe brick has 

> > > come up. 

> > > 

> > > This can be acheived using 8 4Mx4 parts which Euterpe supports, 

> > > but the current PCB design does not. It may not be practical to have 

> > > a single PCB layout support 2 1Mx16, 4 2Mx8, or 8 4Mx4 parts, but 

> > > clearly we could have two different PCBs in that case. The most 

> > > important thing is to be sure we have physical space to accommodate 8 

> > > SDRAM components and that we can cool them in the module. 

> > > 

> > > Tom, pattie, can you look at these issues to make sure the current 

> > > form factor can accommodate this option if it shoud become a hard 

> > > requirement? The 4Mx4 part is in the same package as the 2Mx8. 

> > > 

> > > Tim 

> > 

> > Can the pin interface admit the possibility of using 8 2Mx8 parts 

> > for a 16 MB memory? This requires select pins and additional 

> > capacitance on the data pins, but would permit us to stock 

> > fewer SDRAM part types. It also presumes that 2Mx8 parts are 

> > no less available than 4Mx4 parts. 

> > 

> > Craig 

> > 
> 

> Tom, 

> 
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> Do you know what this would really look like? 

> 

> Right now we have 4 surrounding the 2 in the center, 

> What would this look like? Basicly another set? Where are 

> the connections coming from? 

> 

> Imagine how hou have the 2 x8 parts straddling each of the 1Mx16 

> parts. In the configuration with 8 by 4 parts you would in effect 

> need to straddle each 2Mx8 with 2 1Mx4 parts. 

> 

> As I mentioned in the earlier mail, it's probably not realistic 

> to amke a single board that would support all 3 configurations, 

> or the main issue is how we would fit a total of 8 parts in there. 

> 

> Can we mount a set of 4 on the other side? A piggy back board mount? 

> 

> Mouss has suggested we put all the ram on a daughter card, so we can 

> have different plug in modules. I don't like that idea because it 

> adds complexity, and I don't think doing two euterpe boards for the 2 

> configurations would be any more work than doing 1 pluss a seletciotn 

> of dsaughter cards. 
> 

> >From the scketches I've played with I don't see a fit, but the board 

> size has grown to 6X8 inches? 

> Fd like to get a better understanding of the dimensions and connections, 

> then I can better understand the issue. 

> 

> Perhaps you can stop by Monday morning? 

> 

> As far as the connectivity goes, jay would be best equipped to discuss 
>that. 

> 

>Tim 

> 
> 


Exhibit C12 


Page 390 of 643 


To: 


Subject: 


Sent: 


From: 


Cc: 


tbr 

Monday, March 20, 1995 8:17 PM 
'pmayer (Patricia Mayer)' 
'phililp'; 'pmayer'; 'toe'; 'woody' 
Re: Euterpe Memory 


Follow Up Flag: Follow up 
Flag Status: Red 

Patricia Mayer wrote (on Mon Mar 20): 

Talked to Jay and understand the phsical layout needs but I 
still don't know anything about the parts. 

Do we have anything on this - Philip? 

I left a data book on your desk with the page marked. 

It's the same package as the 2Mx*8. The only difference is that 4 

data lines are no connects on the x4. 


Tim 
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From: paulb (Paul Berry) 

Sent: Monday, March 20, 1995 8:31 PM 

To: 'pandora' 

Subject: Amended 3/10 notes on Mnemosyne heatsinks 


Herman and Tom pointed out conf usioin in the notes as sent . 

What follows replaces the section that in the previous version was headed "PCBs" and "Two 
boards that have Mnemosyne modules" 


Heat sinks for Mnemosyne modules 


Tom: We have adopted larger but fewer fans, using a radial impeller. We should have heat 
sinks in about four weeks for all but the Mnemosyne used in the PCI -mounted PCI -Hermes 
link. 


Three flavors of Mnemosyne modules 


Aside to clarify the discussion: Mnemosynes turn up in three different roles that are 
relevant to Pandora: 


o Pandora's memory controller 

Custom plug -in module: 

- connected to the Hermes channel on the backplane 

- 4 SIMM sockets (with 16 Mbit DRAM< up to 12 8 MB) 


o Pandora's PCI-ISA Bridge module 

Connections to: 

- Hermes channel on the backplane 

- PCI bus on the backplane 

Permits 4 additional cards to be connected to the PCI bus. 

- ISA bus on the backplane 

Permits 5 additional cards to be connected to the ISA bus. 


o PCI -Hermes link 

- In a PC, or in a Pandora, on the PCI bus 

- Standard long PCI card, 

- Provides a link from the PCI bus (of the PC or Pandora) to an 
external Hermes channel (for example, to the Hermes port of a 
Hestia or the Hermes port of another Pandora) 


Heat dissipation for Mnemosyne within a PC 


The heat sink for the Mnemosyne PCI-Hermes link (that is, for the Mnemosyne which may be 
located within a PC) is very large. (At the meeting, Tom estimated 
4 inches square, but later said it will be larger.) 

Mounting the PCI-Hermes link inside a PC imposes height and heat restrictions; for this 
card, we are assuming that the Mnemosyne will generate at most 20 watts (perhaps less, if 
its clock is set slower) . It will rely on natural convection cooling, without additional 
fans . 


Heat dissipation for Mnemosyne within Pandora 


The memory controller (because of its additional RAM) and the ISA bridge module (because 
of its ISA and PCI controllers) will have greater power dissipation than the PCI-Hermes 
link (which will have only a few small components in addition to its Mnemosyne) . However, 
in Pandora, the PCI-Hermes link will have the benefit of forced convection cooling from a 
system- level fan. 

Requirements for the heat sink for the PCI-Hermes links have not yet been fixed. 
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From: Loretta Guarino [guarino@microunity.com] 

Sent: Monday, March 20, 1995 8:32 PM 

To: , mediacom-software@microunfty.com' 

Cc: 'compiler@microunjty.com' 

Subject: March 20 Benchmark Meeting 


We discussed 3 benchmark programs, digital TV, analog TV, and User Interface Demo. For the 
time being we will treat these as 3 independent applications; they make fine technologies 
demonstrations independently, and we avoid a number of systems issues. Eventually, we will 
consider the additional work involved in combining them. 

For this discussion, we also assumed that we have working Hestia hardware. At next week's 
meeting, we'll discussion contingencies plans for using HW as it is likely to become 
available, in stages. 

*'d tasks are not needed for the demos, and will be deferred. 

Global dependencies {tasks needed by all 
applications) 

cache reorganization tool (Scott, compiler 
person) 

DLWS real-time (Tom, Scott) 
Cerberus/Calliope support (khp, gmo) 
Full bootstrap of Euterpe and Calliope {gmo, 
khp) 

Digital TV 


Who: Gregg, Scott, khp, Tom, Doug, qua, ukernel 
person (Gmo) 

Remaining tasks : 

System level encoder, to produce test data 

streams 
audio resampler integration 
QAM integration 

video resampling: test and integration 

DLWS real-time 

time and space budgets 

cache reorganization 

* 3/2 pulldown 

* video resampling (e.g. CIF -> CCIR) 

* closed caption 

* AC- 3 

* changing channels (NIT information, keypad 
support ) 

Analog TV 


Who: Ron, khp, Tom, integration/ukernel person 

Remaining tasks: 

For RF decoding: 
NTSC decoder test 
BTSC audio decode (mono) 
DLWS infrastructure 
time and space budgets 
cache reorganization 

For baseband: 

calliope fixup (DC coupling) 
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User Interface Demo 


Who: Larry, Tom, integration/ukernel person 

Remaining tasks: 

input support (single task) 
♦resource compiler 

TV Guide On Screen (fixed frame background) 
DLWS: complete terp support, transparency, 

alpha blending, spans, filters to avoid 

sharp transitions 

Combined Application 


Tasks : 

input support (multiple tasks) 

flash file system 

overlays 
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From: geert (Geert Rosseel) 

Sent: Monday, March 20, 1995 10:46 PM 

To: Vanthof 

Cc: 'hopper'; 'lisar'; 'tbr' 

Subject: Small Euterpe ready for LVS 

The make finished. Can you restart the LVS on the euterpe 
in the snapshot ? 

Thank's 
Geert 
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From: vanthof (vant) 

Sent: Tuesday, March 21, 1995 12:00 AM 

To: 'Geert Rosseel' 

Cc: 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'tbr (Tim B. Robinson) 1 ; 'Dave Van't Hof 
Subject: Re: Small Euterpe ready for LVS 

Geert Rosseel writes: 

> 
> 

> The make finished. Can you restart the LVS on the euterpe 
>in the snapshot ? 

> 

> Thank's 

> 

> Geert 

> 

The lvs is started on tomato and should be done thursday night. 

Thanks, 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim.h> 
Don't blame me, I didn't vote for him! 
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From: tbr 

Sent: Tuesday, March 21, 1995 12:41 AM 

To: 'Raymond R. Hayes' 

Cc: 'abbott@microunjty.com'; 'gmo@microunity.com'; , gua^ino@mic^ounity.com , ; 

'hay es@microu nity . com' 

Subject: Re: notes on today's meeting 

Follow Up Flag: Follow up 

Flag Status: Red 


Raymond R. Hayes wrote (on Mon Mar 20): 


> I'd say this confirms we need a 16M option for spice. I assume 

> someone among you is more familiar with gcc VM requirements than me, 

> but I expect 8M is more than enough. That leaves only doduc to check 

> as to feasibility for 1 6M. 

> 

> Pending that confirmation, I'd say with high confidence that we could 

> run SPEC without "real" i/o. 

Doduc runs with the OSF simulator's default memory setting. 
For the uninitiated, how much is that? 
Tim 
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From: Guillermo A. Loyola [gmo@microunity.com] 
Sent: Tuesday, March 21, 1995 1:15 AM 
To: 'Raymond R. Hayes'; Tim B. Robinson' 

Cc: 'hayes@microunity.com'; 'guarino@microunity.com'; 'abbott@microunity.com' 
Subject: Re: notes on today's meeting 

The simulator's default is 4Meg. 
Gmo. 
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To: 


Sent: 


From: 


pmayer (Patricia Mayer) 
Tuesday, March 21, 1995 1:25 AM 
'albers'; 'woody* 


Cc: 'pmayer 1 ; 'tbr' 
Subject: Euterpe Module 

Hi Dan. 

I know your working away on Hestia Main. Do you have an idea on 
when the Euterpe Module will be ready for layout? 

I know its basicly the same as a portion of the main board with 
the exception of 2 connectors and I'd like to schedule this with 
some level of accuracy. If we have the Main board Tuesday, could 
we have the module by Thursday? 

Just need to clarify the situation. 


Thanks 
-Pattie 
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From: 
Sent: 


tbr 


To: 


Cc: 


Subject: 


Tuesday, March 21, 1995 1:34 AM 
'pmayer (Patricia Mayer)' 
'albers'; 'pmayer'; 'woody' 
Euterpe Module 


Follow Up Flag: Follow up 
Flag Status: Red 

Patricia Mayer wrote (on Mon Mar 20): 
Hi Dan. 

I know your working away on Hestia Main. Do you have an idea on 
when the Euterpe Module will be ready for layout? 

I know its basicly the same as a portion of the main board with 
the exception of 2 connectors and I'd like to schedule this with 
some level of accuracy. If we have the Main board Tuesday, could 
we have the module by Thursday? 

Just need to clarify the situation. 

I talked to dan earlier this evening, and he said the main board would 
finally be completed in the morning. I requested that he make getting 
the euterpe board higher priority than completing the automation. 
Given it's almost a subset of hestia, I would hope we can get it out 
very quickly after the main board is finalized, and certainly before 
thursday. 

(Dan, let me know if there are any new hurdles!) 


Tim 
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From: pmayer (Patricia Mayer) 

Sent: Tuesday, March 21 , 1 995 1 :39 AM 

To: 'dbulfer' 

Cc: 'tbr'; 'pmayer 1 

Subject: pcb layout schedule 

Hi David! 

I'm trying to get a realisic picture of the PCB layout schedule. 
Hope you can put me back in check. 

The Hestia-Main board was supposed to be in progress but the placement 
is hopefully being saved now. 

The Euterpe module was supposed to start on 3-9 along with Mnemo. I'm 
hoping we have Euterpe by the end of the week and I understand Mnemo 
has a setback. 

Can you help with schematic due dates for the following list of boards? 
BOARDS Current Schedule (obviously wrong!) 


MNEMO 3-9 

Herminator 3*-24 

Back Plane 4-5 

PCI Bridge 4-17 

Cronus 4-26 

PCI Hermes 5-17 

Thanks 
-Pattie 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr 

Tuesday, March 21, 1995 1:56 AM 
'pmayer (Patricia Mayer)' 
'dbulfer'; 'pmayer 1 
pcb layout schedule 


Follow Up Flag: Follow up 
Flag Status: Red 

Patricia Mayer wrote (on Mon Mar 20): 
Hi David! 

I'm trying to get a realisic picture of the PCB layout schedule. 
Hope you can put me back in check. 

The Hestia-Main board was supposed to be in progress but the placement 
is hopefully being saved now. 

The Euterpe module was supposed to start on 3-9 along with Mnemo. I'm 
hoping we have Euterpe by the end of the week and I understand Mnemo 
has a setback. 

Woody should be able to handle mnemo as soon as we have the last 
problems ironed out with Hestia. I had him lower the priority 
relative to work on the Euterpe chip since we did not have the path 
working. Assuming we have Hestia error free tomorrow, when's the 
soonest you need it to avoid being held up? 

Can you help with schematic due dates for the following list of boards? 

BOARDS Current Schedule (obviously wrong!) 


MNEMO 3-9 
Herminator 3-24 
Back Plane 4-5 
PCI Bridge 4-17 
Cronus 4-26 
PCI Hermes 5-17 


Thanks 
-Pattie 
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From: albers (Daniel Albers) 

Sent: Tuesday, March 2 1 , 1 995 1 1 : 1 3 AM 

To: Tim B. Robinson' 

Cc: 'pmayer (Patricia Mayer)'; 'woody (Jay Tomlinson)' 
Subject: Re: Euterpe Module 

> the words of Tim B. Robinson: 

> 
> 

> Patricia Mayer wrote (on Mon Mar 20): 

> 

> Hi Dan. 

> 

> I know your working away on Hestia Main. Do you have an idea on 

> when the Euterpe Module will be ready for layout? 

> 

> I know its basicly the same as a portion of the main board with 

> the exception of 2 connectors and I'd like to schedule this with 

> some level of accuracy. If we have the Main board Tuesday, could 

> we have the module by Thursday? 

> 

> Just need to clarify the situation. 

> 

> I talked to dan earlier this evening, and he said the main board would 

> finally be completed in the morning. I requested that he make getting 

> the euterpe board higher priority than completing the automation. 

> Given it's almost a subset of hestia, I would hope we can get it out 

> very quickly after the main board is finalized, and certainly before 

> thursday. 
> 

> (Dan, let me know if there are any new hurdles!) 


I am re-running the mainboard through the packaging/eco process this 
morning to get some final reference designators picked-up. So the 
board should be available before lunch! 

I don't foresee any hurdles with the euterpe net but will let you 
know asap if any come up... 

Dan 


Daniel Albers albers@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8 1 00 

It can be made into a monster if we all pull together as a team... 
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From: dbulfer (David Bulfer) 

Sent: Tuesday, March 21 , 1 995 1 1 : 1 9 AM 

To: 'Patricia Mayer 1 

Cc: 'dBulfer (David Bulfer)'; 'tbr (Tim B. Robinson)' 
Subject: Re: pcb layout schedule 

I don't have an answer for you today. We can make progress on the 
simple things, like Euterpe, Mnemo-DRAM, and the Herminator. I cannot 
do the design work for the system (backplane, Mnemo-PCI bridge, 
Mnemo-Hermes, etc.) until i get my head out of the Mnemo chip design. 
That will not occur until mid-April. (Alan and I are attempting to 
get basic, crude chip sim up by the end of the month. It will likely 
be a couple more weeks, before the verification interrupts taper 
off.) 

In summary, I will work on some real dates for you. I don't have them 
now. Working with Jay, we could probably come up with Euterpe, 
Mnemo-DRAM, and Herminator designs in a few days from the day he 
starts. 

David 
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From: lisar (Lisa Robinson) 

Sent: Tuesday, March 2 1 , 1 995 6: 1 3 PM 

To: 'tbr'; 'hopper* 

Subject: forwarded message from Bill Zuravleff 

Start of forwarded message 

Return-Path: <billz@godziIla> 

Received: from godziHa.microunity.com by gaea.microunity.com (4.I/musel.3) 

id AA23606; Tue, 21 Mar 95 15:09:20 PST 
Received: by godzilla.microunity.com (8.6.10/muse-sw.2) 

id PAA02482; Tue, 21 Mar 1995 15:09:20 -0800 
Message-Id: <199503212309.PAA02482@godzilla.microunity.com> 
X-Mailer: ELM [version 2.3 PL1 1] 
From: billz@godzilla (Bill Zuravleff) 

To: veena@godzil!a (Veena Malwankar), woody @godzilla (Jay Tomlinson), 
lisar@godzi!la (Lisa Robinson), brian@godzilla (Brian Smith), 
agc@godzilla (Alan Corry) 

Subject: Need Verilog license 

Date: Tue, 21 Mar 95 15:09:19 PST 

Y'all, 

All verilog licenses are in use. If you don't need one 
please relinquish it. 

Thanks, 
billz 

billz.godzilla(54):~/euterpe/verilog/bsrc/nb> verlic 

Imstat - Copyright (C) 1989, 1990, 1991, Highland Software, Inc. 

Flexible License Manager status on Tue 3/21/95 15:07 

Feature usage info: 

Users of VERILOG-XL: (Total of 6 licenses available) 

veena at staypuft on 192.216.192.204:0.0 (v2.000), started Tue 3/21/95 at 13 
:17 

woody at godzilla on hard020:0.0 (v2.000), started Tue 3/21/95 at 14:00 
veena at godzilla on 192.216.192.204:0.0 (v2.000), started Tue 3/21/95 at 14 
:13 

lisar at staypuft on hard004.microunity.com: 0.0 (v2.000), started Tue 3/21/9 
5 at 14:14 

lisar at nosferatu on hard004.microunity.com :0.0 (v2.000), started Tue 3/21/ 
95 at 14:27 

age at godzilla on hardO 14:0.0 (v2.000), started Tue 3/21/95 at 15:04 


end 

End of forwarded message 
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From: billz (Bill Zuravleff) 

Sent: Tuesday, March 21, 1995 6:29 PM 

To: 'brian (Brian Smith)'; Veena (Veena Malwankar)' 

Cc: 'lisar (Lisa Robinson)'; *tbr (Tim B. Robinson)' 

Subject: NB needs standalone testing 

brian or veena, 

OK, a new NB has been released (BOM 1 14) and needs 
thorough standalone testing. I've gone as far as checking 
out the euterpe/verify/standalone/nb portin of the data 
base. Can you tell me (or better yet do for me) how to 
run the standalone tests here. 

Thanks, 
billz 
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From: 


craig 

Tuesday, March 21, 1995 6:45 PM 


Sent: 

To: 

Cc: 


'tbr' 
■billz' 


Subject: 


unpriv access to global virtual address 


I'm developing x86 emulation software that in order to access memory, needs a 48-bit 
address space. Bit 47 's special meaning confounds the problem, and my current plan is to 
use bits 63..48 and 31.. 0 for x86 segment and offset. The current cut-down LTLB only let's 
be use bits 63.. 4 8 when at priviledge level 2 & 3 , which makes protecting other tasks from 
the emulation task difficult. I'd like to get the emulation task to run at priviledge 
level 0, native software to run at priviledge level 1, emulation system software at level 
2 . 

This requires giving priv level 0 the ability to "bypass" the LTLB. A general capability 
for controlling this might involve 4 control bits (or perhaps 3, given that priv level 3 
should always permit "bypass"), one for each priv level, controlling ltlb bypass for all 
threads (we don't need individual control per thread) . 

Do we have the prospect of inserting such control into the Euterpe design? 


Craig 
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From: lisar (Lisa Robinson) 

Sent: Tuesday, March 21 , 1 995 1 1 :58 PM 

To: 'woody' 

Cc: 'jeffrrY; 'tor' 

Subject: dump for stgen 


On nosferatu /s5/euterpe 

Haven't looked to see if it is the same as the ikos trace but I'm sure it will 
be a real problem. 

Good Luck. 

Lisa R. 
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From: 
Sent: 
To: 

Subject: 


chip (Potatoe Chip) 

Wednesday, March 22, 1995 12:19 AM 
'geert* 

output of euterpe/verilog/bsrc/cdio/.checkoutrc 


The output from euterpe/verilog/bsrc/cdio/ . checkoutrc is 160k, so it is not included in 
this mail message. Instead, check the file 

/n/trap/chiplog/geert . rhodan. 26010 . euterpe-verilog-bsrc-cdio 

(which is accessible from all machines) . This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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From: pmayer (Patricia Mayer) 

Sent: Wednesday, March 22, 1995 1 2:30 AM 

To: 'tor' 

Cc: 'pmayer 1 

Subject: good news! 

We're up and running on both Hestia-Main and Pandora-Euterpe. 

I've been trying to run some edits here at home (about 200 parts to place 
and simple setups of the design constraints/DRC's) and its really painfull. 
The Allegro system has many pop-up forms that require redraws when they are 
complete or cancelled. I don't see this as a usefull situation for even 
weekends or evenings. 

Frank had mentioned I might need the ISDN line for graphics and I have to 
agree. The 28.8 modem has been useful for about everything else including 
editing symbol/part data but falls short when editing full database "stuff. 

What do you think? 
-Pattie 


Exhibit C12 


Page 410 of 643 


From: 


tbr 


Cc: 

Subject: 


Sent: 


To: 


Wednesday, March 22, 1995 1:09 AM 
'albers (Daniel Albers)' 

'pmayer (Patricia Mayer)'; 'woody (Jay Tomlinson)' 
pandora euterpe board 


Follow Up Flag: Follow up 
Flag Status: Red 

Daniel Albers wrote (on Tue Mar 21): 

The pandora euterpe board has been packaged and is ready to go. 

Patty, I need a board outline in which to place the final 
packaged net-list. 

Good news, indeed! 

Thanks dan 

Tim 
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From: 
Sent: 


tbr 


Wednesday, March 22, 1995 1:31 AM 
'pmayer (Patricia Mayer)' 
'pmayer 1 
good news! 


To: 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Patricia Mayer wrote (on Tue Mar 21): 

We're up and running on both Hestia-Main and Pandora-Euterpe. 

I've been trying to run some edits here at home (about 200 parts to place 
and simple setups of the design constraints/DRC's) and its really painfull. 
The Allegro system has many pop-up forms that require redraws when they are 
complete or cancelled. I don't see this as a usefull situation for even 
weekends or evenings. 

Frank had mentioned I might need the ISDN line for graphics and I have to 
agree. The 28.8 modem has been useful for about everything else including 
editing symbol/part data but falls short when editing full database "stuff. 

What do you think? 

You should try it on the set up in the machine room. Frank can 
arrange that. If it would be productive we should go ahead with the 
ISDN (assuming it's available in your area). 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Wednesday, March 22, 1995 10:17 AM 

To: 'billz'; 'dickson'; 'jeffm'; 'mws'; 'tbr'; 'woody' 

Cc: 'doi'; 'geert' 

Subject: Test status 


BOM 25 8 running on Zycad 
BOM 25 8 running on IKOS 

New business 

addr_map_void 258 - Data at 8000007f8008 Expected 0, Got 

ffffffffffffffff rhodan /s3 21395.11378 

dcache_except 258 - rhodan /s3 20395.217 94 

DCache Tag exception 2 received when not expected 

Recreated with Accessing same line in new page Old tag had 
exception bit set, no exception bits set GTLB 

dcacheharderS 258 - bad rhodan /s3 21395.11010 dump on staypuft 

/s3/tbr/euterpe 

icache_except 258 - rhodan /s3 20395.21794 

ICache Tag XA exception 1 not received when expected 

Tag m 20000010000d, Tag Addr = 800000e03000 Access addr = 200000100000 
Priv level = 2 XA Priv level = 3 

cachenasty2 25 8 - bad rhodan /s3 213 95.1142 running in verilog 

now 

hermes_conf lict 258 - hung aphrodite /s3 20395.23870 

stgen_rl3311_0 (dram) 258 - Runs okay in verilog off chip but not on 

Ikos. Verilog onchip dump (may be different failure) on staypuft /s3/tbr/euterpe 

stgen_r22478_0 (hermes) 258 - bad trace on aphrodite /s3 17395,18080 dump 
on nosferatu /s5 

dcacheeasy_0 2 57 - X trace on rhodan /s3 20395.23233. 

20395.8790 20395.22590 ( taghz_debug) 
258 - Ran ok 

dcacheharder_0 257 - X trace on rhodan /s3 18395.11180 

258 - Ran ok 

Next group on rhodan /s3 193 95.13268 
cache_U 258 - X 

bgate_U 258 - Understood (nbreject) 

barrel_U 258 - X now but Showed same failure as 

stgen_rl3311 on 253 
interrupt_U 258 

gtlb_miss_U 258 - Showed same failure as stgen_rl3311 on 253 

synch_U 2 58 

instr_U 258 
except ion_U 258 
tlb_U 258 

synch_l 253 - X rhodan /s3 10395.25253 cache_debug 

vldUV_debug 14395.326 

258 - running in verilog now 

atomic conflict 1 250 - Understood 
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xlu field 4 1 


258 - Running now 


dc ac he_per f _s 1 1 t_l 
dcache_perf_ldst5t_l 


250 - Same as stgen__rl3311 
250 - Same as stgen_rl3311 


dcache_conf lict_l 250 Thread 3, Reg 1, Param Entry 2 Expected 
1020304050607 Got f f f f df f f f f f f f f f f - trace on rhodan /s3 11395.6701 

instr_l 251 - Same as cache_U 

258 - X rhodan /s3 21395.23574 


251 - Same as cacheJCJ 
256 - 203 95.22797 - prblm__debug 
258 - 20395.20727 - looks to be still running 

258 - Ran for 5 hours on ikos then ran out of disk space 21395.5155 
258 - X rom image looks to be broken 
Need to reun and if necessary redump these 
250 - X rhodan /s3 11395.6933 


insn_l 

nullTest 
Old Business 
tlb_l 

interleave_l 247 - X and doesn't enable hermes (comment in log 

says otherwise?) nosferatu /s2 11395.15228 
2 58 - running now 


cerbarbeasy_0 


Lisa R to run again as verilog run is well behaved 


Performance Failures (Test ran to completion but failed performance 
measure) 


dcache_j?erf_ldlt_l Expected difference between the cached and 

non-cached access = 4600-5050 cycles 

Actually took 3650 fewer cycles rhodan /s2/perf 24295.8260 
icache_perf_lt_l Expected difference between the cached and 
non-cached access = 46000-50600 cycles 

Actually took 123800 fewer cycles rhodan /s2/perf 

26295.14314 

icache_perf_5t_l Expected difference between the cached and 
non-cached access = 58000-63800 cycles 

Actually took 117120 (!) fewer cycles rhodan /s2/perf 6395.3461 
nb_l Actual accept time = 160:186 Expected accept time 

= 150:180 rhodan /s2/perf 28295.4379 

nb_slow Actual accept time = 160:186 Expected accept time 

= 150:180 rhodan /s2/perf 28295.4379 

nb_hermes Actual Completion Time = 53 0 : 642 Expected 

Completion Time = 250 : 300 aphrodite /s2/ 17395.19127 
nb_combo Param Entry 0 Actual Accept Time = 332 : 490 

Expected Accept Time = 225 : 247 nosferatu /s2 19395.15050 


Have not yet been run: 


hermes_load_0 

hermes_conf lict_l 258 - running now 

ruptpintest_0 - Need to build a "custom" simulator 

inter leave_U 

Cannot yet be run: 


nulltest 
XLU tests 


xlu_rotate_l_l 
xlu_rotate_2_l 
xlu_expand_l_l 
xlu_compress_l_l 
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x lu_ext r ac t_l_l 

xlu_field_l_l 

xlu_field_2_l 

xlu_field_3_l 

x lu_c opy s wap_l_l 

x lu_c opys wap_2_l 

xlu_copyswap_3_l 

x lu_c opy s wap_4_l 

x lu_s hu f f 1 emux_l_ 1 

xlu_select_l_l 

Not yet implemented: 


brcolltest_0 

brcrosstest_0 

brimmlorxgtest_0 

expriotest_0 

canceltest_0 

hermtotest_0 

cerbtotest_0 

hermerrtest_0 

event regtest_0 

exintbashtest_0 

cerberrtest 

cerberror_0 

testerinit_0 

memmap_0 

nbbashtest_0 

cerbarbtests 

hep 11 tests - 2 running ok 

addr_map_mc 
addr_map_c e rb 
addr_map_hermes 

node -boot 


Exhibit C12 


Page 415 of 643 


From: pmayer (Patricia Mayer) 

Sent: Wednesday, March 22, 1995 10:45 AM 

To: 'fgp' 

Cc: 'tbr'; 'pmayer' 

Subject: Re: good news! 


> From tbr Tue Mar 21 22:30:42 1995 

> From: tbr (Tim B. Robinson) 

> To: pmayer (Patricia Mayer) 

> Subject: good news! 

> 

> Patricia Mayer wrote (on Tue Mar 21): 

> 

> We're up and running on both Hestia-Main and Pandora-Euterpe. 

> 

> I've been trying to run some edits here at home (about 200 parts to place 

> and simple setups of the design constraints/DRC's) and its really painfull. 

> The Allegro system has many pop-up forms that require redraws when they are 

> complete or cancelled. I don't see this as a useful 1 situation for even 

> weekends or evenings. 
> 

> Frank had mentioned I might need the ISDN line for graphics and I have to 

> agree. The 28,8 modem has been useful for about everything else including 

> editing symbol/part data but falls short when editing full database "stuff'. 

> 

> What do you think? 

> 

> You should try it on the set up in the machine room. Frank can 

> arrange that. If it would be productive we should go ahead with the 

> ISDN (assuming it's available in your area). 

> 

>Tim 


Frank, 

Can you please set this test up? Let me know when your ready. 

Thanks 
-Pattie 
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From: 
Sent: 
To: 

Subject: 


chip (Potatoe Chip) 

Wednesday, March 22, 1995 11:33 AM 
'geert' 

output of euterpe/verilog/bsrc/au/.checkoutrc 


The output from euterpe/verilog/bsrc/au/ . checkoutrc is 224k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/geert . staypuf t . 6303 . euterpe-verilog-bsrc-au 

(which is accessible from all machines). This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 


Exhibit C12 


Page 417 of 643 


Subject: 


Sent: 
To: 

Cc: 


From: 


torn (Tom Laidig (tau)) 

Wednesday, March 22, 1995 1:22 PM 

'john mudge' 

'warren (Mark Warren)'; 'tau'; 'geert (Geert Rosseel)'; Vo (Tom Vo)' 
Re: Euterpe 


john mudge writes: 
Tom, 

We are thinking about making probe cards and D.U.T. boards etc. for 
euterpe. Where can we find the layout and pad list that will match 
what we are sending to the mask shop? 

I believe (hopefully geert or vo will correct me if I'm wrong) you can find the best info 
under /u/chip/snapshots/euterpe (the new /u/chip/snapshots directory now has symlinks to 
all our snapshot disks, so we don't have to keep hunting in /n/auspex/s???) . The layout 
should be accessible with a vlsi.boo file based on compass/vlsi .boo-all, and I think the 
pin list you want is baseplate/padlist . 1st . 
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From: 
Sent: 
To: 

Subject: 


chip (Potatoe Chip) 

Wednesday, March 22, 1995 2:22 PM 

'geert' 

output of euterpe/verilog/bsrc/at/.checkoutrc 


The output from euterpe/verilog/bsrc/at/ . checkoutrc is 424k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/geert . ghidra . 123 02 . euterpe-verilog-bsrc-at 

(which is accessible from all machines) . This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Wednesday, March 22, 1995 6:42 PM 
'vo (Tom Vo)' 

'vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'geert (Geert 
Rosseel)'; 'tbr (Tim B. Robinson)' 
mnemo shorts test 


Hi Tom 


The mnemo shorts test has died once again, but this time at a point where I can at least 
tell you names that are shorted. Here's the scoop: 

The mnemo database is of such a size, that a single partition will not contain all the 
files. It died about 6 times during a single run, each time requiring certain files to be 
moved and linked back in. I'm going to try again, but this time using a mode of dracula 
which allows single files to be split across file systems. This is much slower, and the 
last time I tried it I believe it had bugs, but I don't remember. 

There are plenty of shorts in the database in addition to floating 
nwells (35 of these) . There are too many geometries to even begin 

to generate an output file. But maybe you can find some commonality based on the node 
names involved in the short. 

This shorts test was started over a week ago on the version at that time in /u/chip. 
Here's the shorts list: 


* /w* 

WaPTJTTJft 
HfilUN J.ViK3 

* * 

TEXT 

TPOUT V 


2 

SHORT 


* /w* 

»v^-i_KJ.N _LlNkj 


TEXT 

SN3 ABM 


2_ 

SHORT 


* /w* 

WARNING 

** 

TEXT 

SC AM 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

SD BM 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

SN2 ABM 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

+ * 

TEXT 

SN1 ABM 


1 

SHORT 

DISCARDED 

*/ W * 

WARNING 

* * 

TEXT 

SNO ABM 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#2 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

* * 

TEXT 

#3 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

** 

TEXT 

#4 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

** 

TEXT 

VDDTS 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DINVRRO_ 

ABM 

1 

SHORT 

DISCARDED 

*/W* 

WARNING 

** 

TEXT 

BISTEN ABM 

1 

SHORT 

DISCARDED 

*/W* 

WARNING 

* * 

TEXT 

DINVRR2 

_ABM 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

VPLL 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

** 

TEXT 

XVDDA V 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

* * 

TEXT 

XRES V 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

* * 

TEXT 

TCLK ABD1PH 

1 

SHORT 

DISCARDED 

*/W* 

WARNING 

** 

TEXT 

DINVRR1 

ABM 

1 

SHORT 

DISCARDED 

*/W* 

WARNING 

* * 

TEXT 

#5 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#6 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#7 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

* * 

TEXT 

#8 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

+ * 

TEXT 

#9 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

* * 

TEXT 

#10 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#11 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#12 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#13 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#14 


1 

SHORT 

DISCARDED 

*/ w * 

WARNING 

** 

TEXT 

#15 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

* * 

TEXT 

#16 


1 

SHORT 

DISCARDED 

*/W* 

WARNING 

* * 

TEXT 

#17 


1 

SHORT 

DISCARDED 

*/ w * 

WARNING 

** 

TEXT 

#18 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#19 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#20 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#21 


1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#22 


1 

SHORT 

DISCARDED 
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*/w* 

WARNING 

** 

TEXT 

#23 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#24 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#25 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#26 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#27 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#28 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#29 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#30 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#31 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#32 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#33 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#34 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#35 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#36 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#37 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#38 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#39 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#40 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

#41 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#42 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#43 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

#44 



1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO 

ABM 

71 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQHl" 

ABM 

71 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO_ABM_ 

7 0 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHI 

ABM 

70 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQLO" 

ABM 

69 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHl" 

ABM 

69 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO 

ABM 

68 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHI 

ABM 

68 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLCT 

_ABM 

67 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQHl" 

ABM 

67 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQLO 

ABM 

66 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHl" 

_ABM_ 

66 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQLO" 

ABM _ 

65 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQHl" 

ABM 

65 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQLO" 

ABM 

_64 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHl" 

_ABM_ 

_64 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO" 

ABM 

63 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO 

ABM 

51 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHl" 

ABM 

_51 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQLO ABM 

50 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

*•* 

TEXT 

DQHI 

ABM 

50 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQLO 

ABM 

49 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHl" 

ABM 

4 9 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO 

ABM 

4 8 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQHl" 

ABM 

_4 8 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO_ 

_ABM_ 

47 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHl" 

ABM 

4 7 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO 

ABM 

4 6 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQHl" 

ABM 

_46 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO 

ABM 

4 5 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQHl" 

ABM 

4 5 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQLO 

_ABM_ 

_44 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHl] 

]abm_ 

_44 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQLO" 

~ABM~ 

43 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

DQHI 

ABM 

"4 3 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQHl" 

ABM 

41 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* + 

TEXT 

DQLO" 

"ABM 

"4 0 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

PCIMODE ABM 

1 

SHORT 

DISCARDED 

* /w* 



1 XiA I 

VSSI 



U_ 

SHORT 


*/w* 

WARNING 

* * 

TEXT 

DQLO 

ABM 

39 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

** 

TEXT 

DQHI 

~ABM_ 

4 0 

1 

SHORT 

DISCARDED 

*/w* 

WARNING 

* * 

TEXT 

VDDl" 



1 

SHORT 

DISCARDED 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 
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255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 #include <std_disclaim . h> Don't blame 
me, I didn't vote for him! 
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From: vo {Tom Vo) 

Sent: Wednesday, March 22, 1995 6:50 PM 
To: 'vant' 

Cc: Vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'Geert Rosseel'; Tim B. 
Robinson' 

Subject: Re: mnemo shorts test 

vant wrote .... 

> 

> 

>Hi Tom, 

> The mnemo shorts test has died once again, but this time at a point where 
>I can at least tell you names that are shorted. Here's the scoop: 

> 

>The mnemo database is of such a size, that a single partition will not 
>contain all the files. It died about 6 times during a single run, each 
>time requiring certain files to be moved and linked back in. I'm going to 
>try again, but this time using a mode of dracula which allows single files 
>to be split across file systems. This is much slower, and the last time I 
>tried it I believe it had bugs, but I don't remember. 
> 

>There are plenty of shorts in the database in addition to floating 

>nwells (35 of these). There are too many geometries to even begin 

>to generate an output file. But maybe you can find some commonality based 

>on the node names involved in the short. 

> 

>This shorts test was started over a week ago on the version at that time 
>in /u/chip. 

> 

>Here's the shorts list: 

> 

> <snip> 

I can't discern any pattern from the list . I guess it's time for quadrant 
short runs on the latest mnemo in /u/chip . 

tvo 
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Subject: 


Sent: 

To: 

Cc: 


From: 


doi (Derek Iverson) 

Wednesday, March 22, 1995 8:53 PM 

'guarino'; 'gmo'; 'sandeep'; 'jeffrrV; 'gregg' 

'hestia' 

Software Bringup Meeting Minutes - March 22, 1995 


Software Bringup Meeting 


March 22, 1995 


Next Meeting: 


March 29 at 10:00 am. 


Attendees: guarino, gmo, sandeep, jeffm, doi, gregg, lisa 


New Action Items 


None. 


Review of Action Items 


Item: Can a single cylinder (in an exception "loop') lock out other 
cylinders? 
Who : j ef f m 
Status : Done . 

03/08 Jeff needs to talk with mws . 
03/18 No progress. 

03/22 Jeff is going to add a note to verify.html mentioning that 
we need to investigate the behaviour of a bback/ exception 
to see if can cause other cylinders to be locked out. 


Item: Terp needs to model "guaranteed forward progress for cache miss' 

in the same fashion as the hardware does. 
Who : lisa 

Status: In progress. 

03/01 Lisa has contacted mws and is implementing the same scheme 

used by the hardware. 
03/08 Still in progress. 
03/15 Progress continues. 

03/22 Ditto. Jeffm mentioned that cachenasty2 doesn't work with terp. 


Item: Tests need to be written to verify performance issues 
Who: lisar, claseman 
Status: In progress. 

02/22 We need to flag performance problems as errors. 

Tests could be identified (and perhaps written) to measure 
and verify performance of the hardware for things like cache 
misses, tlb initialization, exceptions, etc. 

03/01 Lisar has started writing these tests. 

03/08 Work continues. 

03/15 Tim Claseman is assisting. 

03/22 We need to generate a list of tests that we think should be 
written 
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first. Jeff suggested dcache fills, icache fills, dram and hermes 
accesses . 

Item: Determine what additional terp features are required 

(formally "Status of Euterpe/Mnemo simulation') 
Who: gmo, jeffm 
Status: Pending. 

02/08 Jeffm figured that in 2 - 3 weeks time there would be a need 

for terp/mnemo capability to support the verification effort. 

An issue was raised that this may not be enought time for the 

required additions to terp to be made. 
02/15 Gmo is to create a list of requested features for terp and 

then he and jeffm {and others?) are to review the list and 

determine what will be implemented by terp. 
02/22 Gmo is ready to circulate the list. 
03/01 Nothing new. 

03/08 Gmo has shown a group of people the list but will post it. 
03/15 Still pending. 
03/22 Ditto. 


Suspended Items 


Item: Unsnap code 

Who : sandeep , guarino 

Status: Suspended. 

02/15 The issue of restarting the hardware from an IKOS dump 

was discussed and the need for an architectural snap/unsnap 
facility was questioned. 

Since the meeting it has been re-discovered (jeffm wasn't there 
to remind us of an earlier decision) that we are planning on 
loading architectural state into an IKOS simulation and not 
from a total IKOS logic dump. 

We also determined that when it came time to run some 
of the larger tests (real-time benchmark) we would need 
the capability to start an IKOS simulation from an 
architectural dump anyhow. 
03/01 For the short term we are going to focus on a simpler 
approach for loading and running DVTs, the kernel, and 
kernel tests. This item will likely come back in April. 


Item: Refine remote debugging environment 

Who : sandeep 

Status : Suspended 

02/08 We have to decide how control (and state) is to be returned 

to the debug stub after a test runs. 
02/15 Sandeep is not going to have time to start on this for a while. 


Item: Create performance test plan 
Who: . jeffm, guarino 

Status: [11/30] No progress as focus is on functionality. 

We continue to run tests to help us compare terp vs hardware 
performance. 

We still need to put together the actual performance tests that 
need to be run on the hardware. 


Completed Items 
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Item: Build tests that access and run in a bunch of memory spaces and 

states . 

Who : doi 

Status : Done . 

03/08 The test currently runs out of ibuffer but accesses data out 
of dbuf, dram, and hermes devices. The support to build 
the tests that specify hermes data regions in in progress (mkimg) . 

03/18 Support for hermes (including interleave) have been added. Still 
working on support for execution out of different regions. 


Item: Presentations on boot, gdb support, ukernel, ... 
Who : sandeep 
Status : Done . 

03/22 Brief presentation on some of the more interesting chunks 

of code for nanoboot, boot, debugger support, ukernel entry, etc. 


Item: Build microkernel tests for IKOS 
Who: doi, sandeep 
Status : Done . 

02/08 Create images for boot test, snapshot images for microkernel 
tests . 

02/15 doi is still working on modifying the makefiles to build 
the _1 and __2 versions of this. 

iimura is creating a tool that modifies the ELF headers to 
have the proper real addresses (not just virtual) and gmo has 
modified mkimg to be able to understand the new headers. 

02/22 lisar says there are still problems building this. 

iimura is generating a code segment that will run in both 
rom and cerbrom that will proberly initialize dram 
and then branch to the test (which is in dram) . 

03/01 Sandeep is going to add code to boot so it can figure out 
if the cerb node is zero or eight. 

Derek is to start building the kernel tests so they may be 
loaded and run on the hw simulators. 
03/08 Ready to be built for hardware. 

03/15 Changes were made to libc and the microkernel (end- of -test 
support) . 

Sandeep has also created a dummy_boot that will allow us to 
preload the microkernel to speed up simulation times. These 
changes should be available today. 
03/22 The null test has been built and made ready to run with the 
hardware simulators. 


Item: Test interleaved access 
Who: guarino, lisar 
Status : Done . 

02/08 Loretta started to look at this but requires terp support. 

Terp changes are on hold until the real-time benchmark is 

is running again. 
02/22 Test has been written (interleave) but has not been run on 

hwterp yet. Lisar is going to run this on the hardware simulator. 
03/01 The test has been built, but not run yet. Derek is to check 

to be sure the hermes channels are enabled. 
03/08 Ready to run on HW. 

03/15 The tests generated by "stgen' are also capable of testing 

interleaved accesses . 
03/22 Loretta' s test has been written (and run) and Derek's stgen 

also included interleaved accesses. This item is no longer 

being tracked. 
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Test Status and General Discussion 


Jeff talked about current HW and test status. 
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Sent: 
To: 


From: 


pmayer (Patricia Mayer) 
Wednesday, March 22, 1995 8:57 PM 
'albers'; 'woody'; 'howard'; 'tbe' 


Cc: 'tor'; 'pmayer' 
Subject: Things to do list 

Just a list of things to do for both Pandora-Euterpe and Hestia-Main; 

♦Check the electrical/gyg conversions and edits to specifications. 
If we had a list of new and changed files, Howard could work on 
this while his database is being fixed. 

*Pinout forpl50_00002 is switched. 

♦Need Pro-E to Allegro mechanical working. License? 

♦Reorder the 1 60pin connector. 

♦Need global nets connected. 

Anything else? 
-Pattie 
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From: woody (Jay Tomlinson) 

Sent: Thursday, March 23, 1995 12:13 AM 

To: 'pmayer (Patricia Mayer)' 

Cc: 'albers'; 'howard'; 'pmayer'; 'tbe'; 'tor' 

Subject: Things to do list 

Patricia Mayer wrote (on Wed Mar 22): 
Just a list of things to do for both Pandora-Euterpe and Hestia-Main: 

* Check the electrical/gyg conversions and edits to specifications. 
If we had a list of new and changed files, Howard could work on 
this while his database is being fixed. 

to generate the list: 
cd morpheus/gyg 
cvs log BOM [ more 

(note the BOM revision that is just before the date the pcb shipped.) 

(note the most recent BOM) 
cvs diff -r recent_BOM_revision -r old_BOM_revision BOM >gygflles.tobe.reviewed 

the file gygfiles.tobe. reviewed contains the list of .gyg files that need to be 
reviewed. 


woody 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Thursday, March 23, 1995 3:43 AM 
'vant' 

'geert (Geert Rosseel)'; Vanthof (Dave Van't Hot)'; 'lisar (Lisa Robinson)'; 'tbr (Tim B. 
Robinson)'; 'vo (Tom Vo)' 
Re: euterpe Ivs progressing 


vant writes: 


Geert, 


The euterpe small lvs is running fine. There are no shorts between labeled 
nodeds and the device counts match up fine except for 1 
extra mos device in the 

layout . This run should be better than the last . 

The compare stage is running and should be done about 10pm tonight. 


Sounds much better, could the 1 extra device be in the corner pad test area? 


Thanks , 
Dave 


-hopper 
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From: vanthof (vant) 

Sent: Thursday, March 23, 1 995 1 0:25 AM 

To: 'geert (Geert Rosseel)' 

Cc: Vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'lisar (Lisa Robinson)'; 'tbr (Tim B. 

Robinson)'; 'vo (Tom Vo)' 
Subject: euterpe Ivs progressing 


Geert, 

The euterpe small lvs is running fine. There are no shorts between labeled nodeds and 
the device counts match up fine except for 1 extra mos device in the layout. This run 
should be better than the last. 

The compare stage is running and should be done about 10pm tonight. 

Thanks , 
Dave 

Dave Van't Hof vanthof@microunity . coin MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 ftinclude <std_disclaim .h> Don't blame 
me, I didn't vote for him! 
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Subject- 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Thursday, March 23, 1995 10:25 AM 

'KurtWampler' 

'torn (Tom Laidig)'; 'wingard (Drew Wingard)'; 'geert (Geert Rosseel)' 
Re: SVR response 


Kurt Wampler writes: 

Tom & I were talking about writing our own post -placement permuter which 
could be smart enough to permute (D, Q) / (D* , Q* ) pairs, and even permute 
<D,D*,SEL) input groups on muxes. This would be a moderately complicated 
program to write, and I don't know how to quantify the benefit we would 
get from doing it without implementing it and testing it, but intuitively 
it seems like it might help. 

To do this more advanced type of permutation, we would need auxiliary 
equivalence information in a form that can ' t be represented in the current 
" .dff" schema. This could be supplied in an adjunct file in the leafgen 
area. We would also need to decide what criteria were to be used for 
pin assignment -- netbox minimization -- route-order-dependent-gravity etc. 

Even if we implemented all of this, the router would be stuck with static 
connectivity, since it doesn't have the ability to permute pins on the fly 
while it's routing. 

Does an in- house GEARS -based permuter sound like it would be worth the 
investment of resources it would take to implement one? (Wet finger 
estimate: 2-4 weeks?) 


Thanks for working on this. Let me kick it around a bit. My first reaction is that if 
this tool seems only applicable to Euterpe probably it is not worth the effort. On the 
other hand if we thought this tool would be generally useful (for example on Cronus) then 
it is worth proceeding. 

I just mentioned this to Drew and he reminded me that we will have wide (up to 17 input) 
fan-in dynamic AND and OR gates on Cronus. It does seem like these could profit from pin 
permutation. We hope to have a first route of Cronus next week/ perhaps we should wait 
until then to see how bad or good things look and make a decision then. 


Kurt- 


- hopper 
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From: albers (Daniel Albers) 

Sent: Thursday, March 23, 1995 11:14 AM 

To: 'Patricia Mayer' 

Cc: 'woody (Jay Tomlinson)'; 'howard (Howard Cowles)'; 'tbe (Tom Eich)'; Tim B. Robinson'; Patricia 
Mayer' 

Subject: Re: Things to do list 

> the words of Patricia Mayer: 

> 

> Just a list of things to do for both Pandora-Euterpe and Hestia-Main: 

> 

> * Check the electrical/gyg conversions and edits to specifications. 

> If we had a list of new and changed files, Howard could work on 

> this while his database is being fixed. 

> 

> *Pinout for pl50_00002 is switched. 


I fixed this last night. 

> 

> *Need Pro-E to Allegro mechanical working. License? 
We have a temparary licenses which Tom and I have been using. 


> 

> * Reorder the 160pin connector. 

> 

> *Need global nets connected. 
Trying to work on it... 


> 

> Anything else? 

> -Pattie 

> 


Daniel Albers albers@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 

It can be made into a monster if we all pull together as a team... 
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From: vanthof (vant) 

Sent: Thursday, March 23, 1 995 1 1 :43 AM 

To: 'Mark Hofmann' 

Cc: , vanthof@tomato.mic^ou^ity.com , ; 'geert (Geert Rosseel)'; 'lisar (Lisa Robinson)'; 'tbr (Tim B. 

Robinson)'; 'vo (Tom Vo)' 
Subject: Re: euterpe Ivs progressing 


Mark Hofmann writes: 
> 

>vant writes : 
> 

> Geert , 

> The euterpe small lvs is running 

> between 
labeled 

> nodeds and the device counts match 

> extra mos device in the 

> layout . This run should be better 
> 

> The compare stage is running and 
> 

> Thanks , 

> Dave 

> 

>Sounds much better, could the 1 extra 

area? 

> 

> -hopper 


Yes, that was my thought as well. 
Dave 


fine. There are no shorts 

up fine except for 1 
than the last . 

should be done about 10pm tonight, 
device be in the corner pad test 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X276 ^include <std_disclaim . h> Don't blame 
me, I didn't vote for himi 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 23, 1995 2:59 PM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/sr BOM 59.0 initiated by dickson completed @ Thu Mar 23 
11:57:55 PST 1995 with exit status 0.. chip 
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From: torn (Tom Laidig (tau)) 

Sent: Thursday, March 23, 1995 3:03 PM 

To: 'John Campbell' 

Cc: 'tau'; 'lisar (Lisa Robinson)'; 'ericm (Eric Murray)'; 'tbr (Tim B. Robinson)' 
Subject: Re: How bout an auspex disk?? 

John Campbell writes: 

I 

1 1 would like to consider starting another build before the weekend 
jwhich may run to completion if we are lucky. Lisar really wants this 
jon an auspex and may be willing to negotiate deleting some of the chip 
| dinosaurs. 

I 

jwhats chances of negotiating that today at some convenient break in 
jthe action so we can do a getbom tonight?? 

OK, I've gathered some data that might be useful. First, here are the 
current df stats for the auspex disks, sorted by free space: 


Filesystem kbytes used avail capacity Mounted on 

auspex3:/s8 4158078 13 3742258 0% /N/auspex3/s8 

auspex3:/s7 4158078 957255 3159243 23% /N/auspex3/s7 

auspex3:/s47 4158391 2435238 1681570 59% /N/auspex3/s47 

auspex3:/s45 4158007 2642934 1473493 64% /N/auspex3/s45 

auspex3:/s48 4158086 2279311 1462967 61% /N/auspex3/s48 

auspex3:/s40 1847292 648163 114371 1 36% /N/auspex3/s40 

auspex3:/s!3 1225197 13 1114917 0% /N/auspex3/sl3 

auspex3:/s41 1847292 676428 1078500 39% /N/auspex3/s41 

auspex3:/sll 1223389 360522 740529 33% /N/auspex3/sl 1 

auspex3:/s!6 1225197 452300 650378 41% /N/auspex3/sl6 

auspex3:/s28 1847292 1136674 525889 68% /N/auspex3/s28 

auspex3:/s36 1849596 1154023 510614 69% /N/auspex3/s36 

auspex3:/s29 1847292 1210637 451926 73% /N/auspex3/s29 

auspex3:/s21 612590 101632 449699 18% /N/auspex3/s2 1 

auspex3:/s25 1847292 1215148 447415 73% /N/auspex3/s25 

auspex3:/s3 1240589 729470 387061 65% /N/auspex3/s3 

auspex3:/s26 1847292 1300990 361573 78% /N/auspex3/s26 

auspex3:/s43 1848572 1412075 344069 80% /N/auspex3/s43 

auspex3:/sl5 1223645 769673 331608 70% /N/auspex3/sl5 

auspex3:/s42 1848572 1425117 331027 81% /N/auspex3/s42 

auspex3:/s44 2310323 1965578 321642 86% /N/auspex3/s44 

auspex3:/s27 1848572 1354406 309309 81% /N/auspex3/s27 

auspex3:/sl 1240589 808776 307755 72% /N/auspex3/sl 

auspex3:/s46 4158007 3820304 296123 93% /N/auspex3/s46 

auspex3:/s39 1847292 1459548 295380 83% /N/auspex3/s39 

auspex3:/s5 1240589 856017 260514 77% /N/auspex3/s5 

auspex3:/s32 1847292 1590292 238528 87% /N/auspex3/s32 

auspex3:/sI4 1223389 872349 228702 79% /N/auspex3/sI4 

auspex3:/s24 1848572 1475058 188657 89% /N/auspex3/s24 

auspex3:/s!7 1223389 962084 138967 87% /N/auspex3/sl7 

auspex3.7s23 1847292 1524345 138218 92% /N/auspex3/s23 

auspex3:/sl8 1223645 971359 129922 88% /N/auspex3/s 1 8 

auspex3:/s6 1240589 1009991 106540 90% /N/auspex3/s6 

auspex3:/s20 1225197 1015942 86736 92% /N/auspex3/s20 

auspex3:/s35 1847292 1587871 74692 96% /N/auspex3/s35 
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auspex3:/s22 1847292 1593606 68957 96% /N/auspex3/s22 

auspex3:/s37 1847292 1688868 66060 96% /N/auspex3/s37 

auspex3:/s31 1847292 1768565 60255 97% /N/auspex3/s3 1 

auspex3:/s4 1240589 1063340 53191 95% /N/auspex3/s4 

auspex3:/s33 1848572 1778826 51261 97% /N/auspex3/s33 

auspex3:/s9 1240589 1066822 49709 96% /N/auspex3/s9 

auspex3:/sl9 1223389 1054989 46062 96% /N/auspex3/sl9 

auspex3:/s2 1240589 1074219 42312 96% /N/auspex3/s2 

auspex3:/s34 1847292 1620896 41667 97% /N/auspex3/s34 

auspex3:/s!2 1223645 1064752 36529 97% /N/auspex3/sl2 

auspex3:/sl0 1240589 1084158 32373 97% /N/auspex3/sl0 

auspex3:/s38 1847292 1737833 17095 99% /N/auspex3/s38 

auspex3:/s30 1848572 1651112 12603 99% /N/auspex3/s30 

Second, since it seems the older snapshots are not heavily accessed, we 

could probably free up some space by migrating them to other disks, 
s on rama. Rama's disks now look like: 


Filesystem kbytes used avail capacity Mounted on 

rama:/s9 1290069 556763 604300 48% /N/rama/s9 

rama:/s2 1077303 487301 482272 50% /N/rama/s2 

rama:/s6 1233006 895923 312423 74% /N/rama/s6 

rama:/sl 1152416 780503 256672 75% /N/rama/sl 

rama:/s3 1077303 794496 175077 82% /N/rama/s3 

rama:/s4 1233006 1076197 132149 89% /N/rama/s4 

rama:/s5 1233006 1120764 87582 93% /N/rama/s5 


The snapshots are: 

Snapshot kbytes Mounted on 

calliope-0 (w/ proteus) 113064 /N/auspex3/s28 

castor (w/ proteus) 114079 /N/auspex3/s28 

pollux (w/ proteus) 8 1 89 1 /N/auspex3/s28 

orchis (w/ proteus) 83 1 478 /N/auspex3/s25 

calliope 1617236 /N/auspex3/s30 

calliope/proteus 268804 /N/auspex3/s28 

euterpe 676418 /N/auspex3/s41 

euterpe/proteus 997843 /N/auspex3/s23 

So it looks to me as if one option to free up more auspex space would be 
to distribute the stuff from s28 onto rama's disks. 

Anyway, I'll be around til about mid-afternoon today. Maybe we can dig 
up ericm or whoever, and come up with some plan. I dunno what the 
existing plans there may be for the auspex disks (or rama's disks, for 
that matter). 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 23, 1995 4:16 PM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/mst BOM 35.0 initiated by dickson completed @ Thu Mar 23 
13:14:37 PST 1995 with exit status 0.. chip 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 23, 1995 5:04 PM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/cdio BOM 45,0 initiated by dickson completed @ Thu Mar 2 3 
14:03:31 PST 1995 with exit Status 0.. chip 

lock read: File exists 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 23, 1995 5:19 PM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/cc BOM 72.0 initiated by dickson completed @ Thu Mar 23 
14:18:28 PST 1995 with exit status 0.. chip 

lock read: File exists 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Scott Furman [fur@microunity.com] 
Thursday, March 23, 1995 5:26 PM 
'Loretta Guarino' 
'gregg@microunity.com' 
critical instruction sequences? 


Loretta Guarino writes : 

> Do either of you have any candidate instruction > sequences for performance tests? 
Critical inner > loops that we should measure on the HW > simulator? 


1) IDCT code (There's already a standalone test for this.) 

2) pseudo- Huffman decode loop (stb/lib/mpeg/video/parse_mb.c:24 6) 
(See also an earlier note I sent to Ray, reproduced below.) 

3) Any macroblock reconstruction routines in macroblock.c 
(For example, reconstruct_uni_macroblock ( ) in 

stb/lib/mpeg/video/macroblock. c : 152 ) 

4) The core NTSC encode loop in stb/ukernel/dev/video-out . c, lines 
357 to 410. 

5) rs_compute_syndrome { ) in stb/lib/f ec/rs_syndrome . c 

Let me know if you have any questions about this code, what context it runs in, etc. 


Notes on pseudo-Huffman inner loop in parse_mb.c: 

This is the heart of the DCT coefficient Huffman decoder. For 
worst -case input, the 12 -instruction loop below should account for 
nearly half of the cycles spent parsing MPEG input data. {The 
remaining cycles are expended in a much larger body of code that 
compiles to several thousand instructions. Less effort has been spent 
on optimizing these other types of MPEG data parsing routines because 
they are less "dense" . ) 

It should be pointed out that the chosen Huffman- decoding algorithm 
was designed with our current microarchitecture in mind. With a 
different set of constraints, this Huffman decoder might have been 
designed very differently. For example, if branch misprediction 
penalties and memory- op issue restrictions were less severe, it might 
be cheaper to compute a branch address based on the first few leading 
bits of the bitstream. In this case, there would be a separate code 
sequence for each possible combination of leading bits, allowing 
multiple codewords to be decoded at the same time. 

The loop below performs a direct "fast" table lookup based on the 
leading nine bits of the variable- length code (VLC) . If the VLC is 
short enough that these few bits completely specify the codeword, the 
DCT coefficients are reconstructed from data in the table entry. 
Otherwise, the fast decoding is aborted and control is transferred to 
an "exception" dispatcher that completes the decoding. 

An "exception" occurs when: 

A) We've run off the end of our 8x8 matrix, which indicates the 
presence of illegal input data, or 

B) The VLC was not a "short" codeword. It must be one of these: 

1) end-of -block code 

2} escape- code (followed by escaped run and level data) 
3) "long" codeword (greater than nine bits long) 

By clever encoding of the lookup table entry, we can test for all 
these conditions with a single branch. Each Huffman decoding table 
entry is a triple { LENGTH , LEVEL, RUN} indicating the length of the 
Huffman codeword, the value of the non-zero coefficient and the number 


Exhibit C12 


Page 441 of 643 


of preceding zero coefficients, respectively. Actually , the value 
(RUN +1) is stored in the table rather than RUN, and sometimes the 
table contains an exception code in place of the RUN value. This is 
the layout of a table entry in memory: 


Codeword LEVEL (RUN +1) or 

Length j j exception code 


In the loop surrounding the innermost loop (not shown) , data is parsed 
from the input bit stream in chunks of almost 12 8 bits (actually 117 
bits) . The branch at the end of the loop detects when the single 
hexlet of input data is exhausted. If so, it is refilled from the 
memory-mapped input queue and the loop is restarted. With 
minimum- length coefficients, which are 3 bits long, this buffer hexlet 
should only need to be refilled roughly every 3 0 iterations of the 
inner loop. 

The first iteration of the 12 -instruction loop can be scheduled in 14 
cycles. However, due to issue restrictions on store instructions, 
subsequent iterations must begin on a multiple of 4 cycles, so each 
iteration requires 16 cycles, for an IPC of 0.75. (Note: the code 
below is not presented the way the compiler schedules it. The 
instruction selection is the same, but my scheduling is somewhat 
better than the compiler's.) 


; Cycle Description 


gushrl28 

r2,r6,r36 


; o 

Get leading bits of 

bitstream 







1 

STALL: 

+1 (Regdep) 

eandi 

r2,r2,2044 


; 2 

Get leading 6 bits of 

bitstream 





lu321 

r2, r51, r2 


; 3 

Lookup Huffman table 

entry 







4 

STALL: 

+1 (Regdep) 

eadd 

r3 , r59, r2 


; 5 

Compute new zigzag 

index 





eushri 

r8 , r2 , 8 


; 6 

Get (RUN + 1) (# of 

zeros plus one) 





bandne 

r3, r48, .LG03E 

55 

; 7 

Do we have an 

exception ? 




Mask off unused bits 

eandi 

r59, r3, 63 


; 8 

of index 





lu8 

r3,r53,r59 


; 9 

Convert zig-zag to 

linear index 





eushri 

r4,r2, 24 


; 10 

Get codeword LENGTH 

sl6l 

r8,r57,r3 


; 11 

Store in destination 

matrix 





esub 

r36, r36,r4 


; 12 

Compute new bitstream 

cursor 





biz 

r3 6, .LG041.55 


; 13 

Bitstream underflow ? 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 23, 1995 5:36 PM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/lt BOM 85.0 initiated by dickson completed @ Thu Mar 23 
14:34:47 PST 1995 with exit status 0.. chip 
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Subject: 


Sent: 

To: 

Cc: 


From: 


torn (Tom Laidig (tau)) 

Thursday, March 23, 1995 6:31 PM 

'Mark Hofmann' 

'wampler (Kurt Wampler)'; 'wingard (Drew Wingard)'; 'geerl (Geert Rosseel)*; 'tau' 
Re: SVR response 


Mark Hofmann writes: 
Kurt- 

Thanks for working on this. Let me kick it around a bit. My first 
reaction 

is that if this tool seems only applicable to Euterpe probably it is 
not worth the effort. On the other hand if we thought this tool would 
be generally useful {for example on Cronus) then it is worth proceeding. 
I just mentioned this to Drew and he reminded me that we will have wide 
(up 

to 17 input) fan- in dynamic AND and OR gates on Cronus. It does seem 
like these could profit from pin permutation. We hope to have a first 
route of Cronus next week, perhaps we should wait until then to see how 
bad or good things look and make a decision then. 

A pin permuter would be applicable to cronus as well as euterpe. Simple permutation {as 
gards _could_ do) may even be more useful on cronus than on euterpe, since I think the 
wide fanin gates will tend to have even more densely packed targets in the atlas 
technology. OTOH, the fancier permutability may be of smaller benefit for cronus than for 
euterpe, since the class of permutations based on swapping differential signals won't 
exist. There should still be some usefulness, however, from being able to swap 
data/select pairs on muxes. 

Of course, as Kurt says, it's hard to guess how much benefit this program would provide. 


■ Y 
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From: tbe (Tom Eich) 

Sent: Thursday, March 23, 1995 6:56 PM 

To: 'howard'; 'pmayer (Patricia Mayer)' 

Cc: *tbr (Tim B. Robinson)'; 'philip (Philip Wong)'; 'dbulfer (David Buffer)' 
Subject: SDRAM location 

Hi, 

Because of the design requirement to duct airflow in the Pandora Euterpe 
module, it is optimal from a thermal standpoint to place the SDRAMs on 
the primary side of the pcb (the same side as Euterpe is on). This is 
of course different from the way it was done in Hestia, and from what has 
been layed out so far. It also would require a primary side smt reflow, and 
may have other impacts as well. 

Howard, could you please take a look at the implications of having the 
SDRAMS on the primary side? As I am still finalizing the mechanical 
criteria, it would help to know how and how well this arrangement could 
work. Let's get together tomorrow to discuss. 

Thanks, 

-Tom 
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Subject: 


Sent: 

To: 

Cc: 


From: 


lisar (Lisa Robinson) 

Thursday, March 23, 1995 7:10 PM 

'craig' 

'mouss' 

TSA document 


Craig, 


It had been my intention (and Bob has been working on this) to add to the Euterpe 
MicroArchitecture book all of the implemetation specific details of Euterpe. For example, 
a complete description of the instructions supported by the Euterpe implementation in the 
style of the TSA. 

Hence keeping a distinction beteween the Architecture and the MicroArctecture 
documentat ion . 

However, this has not been well received since there are contradictory implementation 
specific details in the TSA. In addition, it is felt that for many the depth of detail in 
the MicroArchitecture document is too much and they would prefer (for applications 
programmers) a higher level view as is provided by the TSA. 

I would like to be able to address some of the inconsistancies in the TSA in the parallel 
with the additions to the Euterpe MicroArchitecture but as you are aware I do not have 
access to the source. 

In addition, It may be desirable to link the overlapping documentation as a single source. 
Comments? (or a pointer to the source;-) 


PS. Are you comfortable with the level of detail in the MicroArchitecture Books being made 
availble along side other online documents (as is currently the case) . 


Lisa R. 
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From: vanthof (vant) 

Sent: Friday, March 24, 1995 2:26 AM 

To: 'geert (Geert Rosseel)'; Vo (Tom Vo)'; 'lisar (Lisa Robinson)'; Tim B. Robinson'; 'Mark Hofmann' 

Cc: Vanthof (Dave Van't Hof)' 

Subject: mnemo shorts and euterpe Ivs status 


euterpe lvs: 

The output is basically unchanged from the last run. The number 
of unmatched devices is still over 4000. The iobyte and pll errors 
seem to have gone away, but there are now what appears to be opens in 
the layout. 

NUMBER OF UN-MATCHED SCHEMATICS DEVICES = 4099 
NUMBER OF UN-MATCHED LAYOUT DEVICES = 4100 
NUMBER OF MATCHED SCHEMATICS DEVICES = 889160 
NUMBER OF MATCHED LAYOUT DEVICES = 889160 

The output file is: 

/u/vanthof/compass/mobi/euterpe/tapeout/euterpe.compare/euterpe.lvs 


Mnemo shorts: 

- lower left and upper left still running. 

- lower right is clean 

- upper right is not. It has the following shorts: 

VDDI 
VSSI 

There are also floating nwell regions. I'll have to try and 
track these down. 

I have an error file for this short and it's: 

/u/vanth of/compass/mob i/m n emo/mnem our. err 

I'll take a look at this in the morning. 

Thanks, 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 
"Don't blame me! I didn't vote for him" 
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From: tbe (Tom Eich) 

Sent: Friday, March 24, 1995 4:31 AM 

To: 'Patricia Mayer' 

Cc: 'howard'; 'tbr (Tim B. Robinson)'; 'philip (Philip Wong)'; 'dbulfer (David Bulfer)' 
Subject: Re: SDRAM location 

Pattie Mayer wrote: 

> 

> One impact will be the metal ring for the space tab/gasket thing. Were 

> you hoping to use the same ring? An alternative method of routing would 

> be to feed down to the bottom and then back up to the pads. This would 

> nearly double the vias. Other wise theres lots of room on the board! 

> Let me know how it goes. 
> 

> -Pattie 

> 

>> 

> > Because of the design requirement to duct airflow in the Pandora Euterpe 

> > module, it is optimal from a thermal standpoint to place the SDRAMs on 

> > the primary side of the pcb (the same side as Euterpe is on). This is 

> > of course different from the way it was done in Hestia, and from what has 

> > been layed out so far. It also would require a primary side smt reflow, and 

> > may have other impacts as well. 
>> 

> > Howard, could you please take a look at the implications of having the 

> > SDRAMS on the primary side? As I am still finalizing the mechanical 

> > criteria, it would help to know how and how well this arrangement could 

> > work. Let's get together tomorrow to discuss. 

>> 

> > Thanks, 

> > 

> > -Tom 

>> 
> 

Good question, I neglected to say that the metal ring is to my way of 
thinking changeable and so you one could route traces directly from the 
OLB pads to the SDRAM where otherwise possible. Talk to you all soon. 

-Tom 
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From: geert (Geert Rosseel) 
Sent: Friday, March 24, 1995 10:18 AM 
To: 'lisar*; 'tbr'; Vanthof ; 'vo' 
Subject: Euterpe Ivs 

Hi, 

THere are three types of errors in this euterpe : 

1 . Somew inputs to the I-Cache have not been matched up and are regarded 
as floating (They are actually floating) 

2. Two errors at inputs of TTL pads 

3. There is a clock inversion, A large chunk of the clock tree is flagged 
and all flipflops in the register file ... 

Geert 
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From: geert (Geert Rosseel) 

Sent: Friday, March 24, 1 995 1 1 : 1 5 AM 

To: 'billz'; 'dicksmws'; 'hopper'; 'tbr'; 'wampler'; 'woody' 

Subject: Latest top-level route 

Hi, 


I ran a "complete" route on the latest top-level placement ( = 3 days 
old). This is pgroute, special nets route , linesearch and maze. 

The result is about 1950 unroutes after line-search and 500 after maze. 

The pgroute hurt us a bit ( Utile M3 VREF stubs all over the place), but 
the special nets route should have helped. 

I think it is very important to go look at the route now and understand why 
the wires don't route in maze. Most should be due to congestion that we are 
fixing but I am worried that a there are a bunch that will need special 
attention like chaning the routing order or evene baseplate changes (e.g, to 
get to the pads). I will look at the route, Kurt, do you have some time 
to look at the routing results ? 

As always , the stuff lives in /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards2 
(or it will in a short time, I will copy the files now, but it takes 10 
minutes to get it all copied). 


Geert 
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From: pmayer (Patricia Mayer) 
Sent: Friday, March 24, 1995 11:33 AM 
To: 'howard'; 'pmayer'; 'tbe' 
Cc: 'tbr'; 'philip'; 'dbulfer' 
Subject: Re; SDRAM location 

One impact will be the metal ring for the space tab/gasket thing. Were 
you hoping to use the same ring? An alternative method of routing would 
be to feed down to the bottom and then back up to the pads. This would 
nearly double the vias. Otherwise theres lots of room on the board! 
Let me know how it goes. 

-Pattie 

> From tbe Thu Mar 23 23:56:08 1995 

> From: tbe (Tom Eich) 

> Subject: SDRAM location 

> To: howard, pmayer (Patricia Mayer) 

> Date: Thu, 23 Mar 95 23:56:04 GMT 

> Cc: tbr (Tim B. Robinson), philip (Philip Wong), dbulfer (David Bulfer) 

> X-Mailer: ELM [version 2.3 PL1 1] 

> Content-Length: 683 

> 

>Hi, 
> 

> Because of the design requirement to duct airflow in the Pandora Euterpe 

> module, it is optimal from a thermal standpoint to place the SDRAMs on 

> the primary side of the pcb (the same side as Euterpe is on). This is 

> of course different from the way it was done in Hestia, and from what has 

> been layed out so far. It also would require a primary side smt reflow, and 

> may have other impacts as well. 
> 

> Howard, could you please take a look at the implications of having the 

> SDRAMS on the primary side? As I am still finalizing the mechanical 

> criteria, it would help to know how and how well this arrangement could 

> work. Let's get together tomorrow to discuss. 
> 

> Thanks, 

> 

>-Tom 

> 
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From: 
Sent: 
To: 

Subject: 


wampler (Kurt Wampler) 

Friday, March 24, 1995 11:45 AM 

'billz'; 'dicksmws'; 'geert'; 'hopper'; 'tbr'; 'woody' 

Re: Latest top-level route 


Geert writes: 


> I ran a "complete" route on the latest top-level placement ( = 3 days 
>old) . This is pgroute, special nets route , linesearch and maze. 

> 

> The result is about 195 0 unroutes after line- search and 500 after maze, 
> 

> The pgroute hurt us a bit ( lit lie M3 VREF stubs all over the place) , 
but 

>the special nets route should have helped. 
> 

> I think it is very important to go look at the route now and 

> understand 
why 

>the wires don't route in maze. Most should be due to congestion that we 
are 

> fixing but I am worried that a there are a bunch that will need special 
>attention like chaning the routing order or evene baseplate changes 
> (e.g, 
to 

>get to the pads) . I will look at the route, Kurt, do you have some time 
>to look at the routing results ? 

Yes, I'll have a look at it right now. Anyone else that's curious is 
welcome to peruse independently, or drop by for kibitzing. 


> As always , the stuff lives in 

/ n/ghidra/ s3 /geer t/euterpe/ ver ilog/bsrc/gards2 

> (or it will in a short time, I will copy the files now, but it takes 
>10 minutes to get it all copied) . 


- Kurt 


Exhibit C12 


Page 452 of 


From: vo (Tom Vo) 

Sent: Friday, March 24, 1995 1:15 PM 

To: Vant' 

Cc: 'geert (Geert Rosseel)'; 'lisar (Lisa Robinson)'; 'tbr (Tim B. Robinson)'; 'hopper (Mark 

Hofmann)'; 'vanthof (Dave Van't Hof)' 
Subject: Re: mnemo shorts and euterpe Ivs status 

vant wrote .... 

> <snip> 
>Mnemo shorts: 
> 

> - lower left and upper left still running. 
> 

> - lower right is clean 
> 

> - upper right is not. It has the following shorts: 
> 

> VDDI 

> VSSI 
> 

> There are also floating nwell regions. I'll have to try and 

> track these down. 
> 

> I have an error file for this short and it's: 
> 

> /u/ vanthof /compass/mobi/mnemo/mnemo_ur . err 
> 

> I'll take a look at this in the morning. 
> 

> Thanks, 
>Dave 

I think this one can be blamed on operator error . I failed to rebuild the clockbias cell 

1 1 11 start another build . 

tvo 
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From: Tom Vo [vo@rhea] 

Sent: Friday, March 24, 1 995 1 :45 PM 

To: 'Tom Vo' 

Subject: pager log message 


page from vo to geert: 

Fri Mar 24 10:44:44 PST 1995 /s4/vo/euterpe/verilog/bsrc chip_euterpe crashed 
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From: Tom Vo [vo@rhea] 

Sent: Friday, March 24, 1995 1:52 PM 

To: Tom Vo' 

Subject: pager log message 


page from vo to geert : 

Fri Mar 24 10:51:54 PST 1995 /s4/vo/euterpe/verilog/bsrc chip_euterpe crashed 
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From: pmayer (Patricia Mayer) 

Sent: Friday, March 24, 1995 1:53 PM 

To: 'tbr'; 'woody'; 'howard'; 'dbulfer'; 'tbe' 

Cc: 'albers'; 'philip' 

Subject: PCB Schedule 

I dropped off a current schedule for PCB layout on Hestia and Pandora. 
Several questions came up; 

1) What about the Expanded Euterpe SDRAM Module? 

2) Will we need edits to the Front panel arid/or the Power Supply? 

Also, Woody suggested a schematic review for the Euterpe module. 

Any other questions or comments? 
-Pattie 


Exhibit C12 


Page 456 of 643 


From: 
Sent: 
To: 

Subject: 


Tom Eich [tbe@microunity.com] 
Friday, March 24, 1995 4:53 PM 
'pandora@microunity.com' 

IMMINENT DECISION: SDRAMs on Euterpe side of PCB 


We are considering placement of the various configurations of SDRAM and flash ROM on the 
Euterpe (primary) side of the Euterpe Module pcb in Pandora. Recall that is Hestia, these 
parts were on the secondary side opposite Euterpe, 

This decision is being proposed because the best airflow available is on the primary side, 
and ducting will be simpler and less expensive. With respect to manufacturing, the 
micropax connector will require a SMT reflow on that side anyway, and this approach will 
place all the fine pitch components on the same side, which eases inspection. PCB design 
is assessing the routing impact, and if acceptable, we will move to DECISION, unless other 
issues arise. 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94089 
(408)734-8100, (4 08)734-8136 fax 


tbe@microunity . com 
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From: 
Sent: 
To: 

Subject: 


pmayer (Patricia Mayer) 
Friday, March 24, 1995 6:02 PM 
'pandora'; 'tbe@microunity.com' 

Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 


> From tbe@microunity.com Fri Mar 24 13:53:17 1995 

> To: pandora 

> From: tbe@microunity.com (Tom Eich) 

> Subject: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 

> Content -Length: 961 
> 

> We are considering placement of the various configurations of SDRAM 

> and flash ROM on the Euterpe (primary) side of the Euterpe Module pcb 

> in Pandora. Recall that is Hestia, these parts were on the secondary 

> side opposite Euterpe. 
> 

> This decision is being proposed because the best airflow available is 

> on the primary side, and ducting will be simpler and less expensive. 

> With respect to manufacturing, the micropax connector will require a 

> SMT 
ref low 

> on that side anyway, and this approach will place all the fine pitch 

> components on the same side, which eases inspection. PCB design is 

> assessing the routing impact , and if acceptable, we will move to 
DECISION, 

> unless other issues arise. 


tbe@microunity . com 

> MicroUnity Systems Engineering, Inc. 

> 2 55 Caspian Dr. Sunnyvale, CA 94 089 

> (408)734-8100, (408)734-8136 fax 


Reviewed this extensively with Howard and the routing is simplified this way. The traces 
come straight out of Euterpe and to the SDRAMs. 

Woody also reviewed the placement for crossovers and it won't even need to be reordered. 

Howard will first start with a basic metal ring for the spacer and that will determine the 
placement for the RAMs . The FlashRom can also be easily moved to the top. 

This is acceptible and we can move to DECISION unless there are other issues for anyone 
else . 

Also, we will wait for the ProE to Allegro interface to determine the clamp area to place 
the caps. On all future boards we will place the caps, say 3 0-40 mils from the clamp? and 
on the secondary side. 

Any other ideas, please let us know. 


> 


> -Tom 


> 


> Tom Eich 


Thanks 
-Pattie 
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From: Brian Smith [brian@godzilla] 
Sent: Friday, March 24, 1995 6:08 PM 

To: , euterpe-checkins-dist@godzilla'; 'lisar@godzilla'; 'tbr@godzilla'; 'tom@godzilla' 
Subject: euterpe/verify/standalone/hc nbhc_drive.h 

Update of /u/chip/chip-archive/euterpe/verify/standalone/hc 

In directory godziIla:/N/auspex2/sl7/brian/euterpe/veriry/standalone/hc 

Modified Files: 

nbhc_drive.h 
Log Message: 

Forgot to commit this change last time. 
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From: Brian Smith [brian@godzilla] 
Sent: Friday, March 24, 1995 6:09 PM 

To: , euterpe-checkins-dist@godzilla'; , lisar@godzilla'; 'tbr@godzilla'; 'tom@godzilla' 
Subject: euterpe/verify/standalone/hc nbhc_drive.V 

Update of /u/chip/chip-archive/euterpe/verify/standalone/hc 

In directory godzilla:/N/auspex2/sl7/brian/euterpe/verify/standalone/hc 

Modified Files: 

nbhc drive. V 
Log Message: 

Changed he and iorate interfaces for differential reset and a new dhedis 
signal. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Eich [tbe@microunity.com] 
Friday, March 24, 1995 6:54 PM 
'Patricia Mayer' 
, pandora@mic^ounity.com , 

Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 


Pattie Mayer wrote: 

>snip< 
> 

>Also, we will wait for the ProE to Allegro interface to determine the 
clamp 

>area to place the caps. On all future boards we will place the caps, 

>say 30-40 mils from the clamp? and on the secondary side. 

> 

>Any other ideas, please let us know. 


Yes, follow IPC-D-275 relative to the keep- outs, treating them as if they are "protected" 
edges of metal and at unknown potential. I recall either 

.025 or .050" as the spacing for a "protected" spacing. My terminology may be off here, 
but see me if there is still uncertainty. 


> 


> Thanks 
>-Pattie 


-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 9408 9 
(408)734-8100, (408)734-8136 fax 


tbe@microunity . com 
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From: pmayer (Patricia Mayer) 

Sent: Friday, March 24, 1995 7:14 PM 

To: 'pmayer"; 'tbeCgmicrounity.com* 

Cc: 'pandora' 

Subject: Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 


> From tbe@microunity.com Fri Mar 24 15:53:48 1995 

> To: pmayer (Patricia Mayer) 

> From: tbe@microunity.com (Tom Eich) 

> Subject: Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 

> Cc : pandora 

> Content -Length: 84 6 
> 

> Pattie Mayer wrote: 
> 

> >snip< 

> > 

> >Also ( we will wait for the ProE to Allegro interface to determine the 
clamp 

> >area to place the caps. On all future boards we will place the caps, 
say 

> >3 0-4 0 mils from the clamp? and on the secondary side. 

> > 

> >Any other ideas, please let us know. 

> > 

> > Thanks 

> >-Pattie 
> 

> Yes, follow IPC-D-275 relative to the keep-outs, treating them as if 
they 

> are "protected" edges of metal and at unknown potential. I recall 
either 

> .025 or .050" as the spacing for a "protected" spacing. My 

> terminology 
may 

> be off here, but see me if there is still uncertainty. 
> 

> -Tom 


Do we have a copy of the IPC- S- 27 5? 
-Pattie 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tom Eich [tbe@microunity.com] 
Friday, March 24, 1995 7:15 PM 
'Patricia Mayer 1 
'pandora@microunity.com' 

Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 


>> From tbe@microunity . com Fri Mar 24 15:53:48 1995 

>> To: pmayer (Patricia Mayer) 

>> From: tbe@microunity . com (Tom Eich) 

>> Subject: Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 

>> Cc: pandora 

>> Content -Length: 846 


» Pattie Mayer wrote: 
>> 

>> >snip< 
>> > 

>> >Also, we will wait for the ProE to Allegro interface to determine 

>> >the 

clamp 

» >area to place the caps. On all future boards we will place the caps, 
say 

>> >3 0-40 mils from the clamp? and on the secondary side. 
>> > 

>> >Any other ideas , please let us know. 
>> > 

>> > Thanks 
>> >-Pattie 

>> 

>> Yes, follow IPC-D-275 relative to the keep-outs, treating them as if 
they 

» are "protected" edges of metal and at unknown potential. I recall 
either 

» .025 or' .050" as the spacing for a "protected" spacing. My 

» terminology 

may 

>> be off here, but see me if there is still uncertainty. 


>> 


>> 


» -Tom 


>> 


> 


>Do we have a copy of the IPC- S- 2 7 5? 
> 

>-Pattie 


Philip does, I believe. 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94 08 9 
(408)734-8100, (408)734-8136 fax 


tbe@microunity . com 
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From: billz (Bill Zuravleff) 

Sent: Friday, March 24, 1995 7:41 PM 

To: 'euterpe-checkins-disf; 'lisar'; 'tbr'; 'torn' 

Subject: euterpe/verify/standalone/nb Makefile nb_drive.V 

Update of /p/cvsroot/euterpe/verify/standalone/nb 

In directory rhodan:/N/ghidra/s2/euterpe/verify/standaIone/rib 

Modified Files: 

Makefile nbdrive.V 
Log Message: 

A couple of changes: 

1) sendNBdR3 timing — this signal is active on cb2 only. 

2) tau (input to nb) is low during cb4. 

3) added a "peripheral memory" monitor. 

4) Makefile renames dump and pmemlog files to that of testname. 
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From: woody (Jay Tomlinson) 

Sent: Friday, March 24, 1995 8:01 PM 

To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn' 

Subject: euterpe/verilog/bsrc/hc hc_ostate.pla 

Update of /p/cvsroot/euterpe/verilog/bsrc/hc 

In directory clytemnestra:/N/auspex2/s20/woody/chip/euterpe/veriIog/bsrc/hc 

Modified Files: 

hc_ostate.pl a 
Log Message: 

Oops don't turn on cnflctRcrvy when rates are not equal. 
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From: lisar (Lisa Robinson) 

Sent: Friday, March 24, 1 995 8:07 PM 

To: 'Loretta Guarino' 

Cc: 'guarino@microunity.com'; 'hayes@microunity.com'; 'jeffm'; 'tbr* 
Subject: tec vs diagnostics 

Loretta Guarino wrote (on Fri Mar 24): 

How important is it that we finish converting 
(most of) the acceptance tests to use tec 
instead of tgee? I got them fairly far along, 
but there were a few build problems that we 
never solved, relating to the use of the math 
library from onchip and dram. I'd like to know 
whether I should abandon the effort, or whether 
we should push through with getting the tests 
through tec. Comments? 

Loretta 

I think that it is extreemly important to be using tec instead of tgec. 
However, given where we are with repect to tapeout. I'd like to get the 
tests running as they are now and then change over to use tec. 

I can't emphasis enough how important I think that this is. 
Lisa R. 
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From: billz (Bill Zuravleff) 

Sent: Friday, March 24, 1995 8:27 PM 

To: 'euterpe-checkins-disf; 'lisar'; "tbr"; 'torn' 

Subject: euterpe/verilog/bsrc/nb nb.V 

Update of /p/cvsroot/euterpe/verilog/bsrc/nb 
In directory ghidra:/s2/euterpe/verilog/bsrc/nb 

Modified Files: 

nb.V 
Log Message: 

OK, this really and truly passes nb_pri_13! 
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From: pmayer (Patricia Mayer) 
Sent: Friday, March 24, 1995 8:30 PM 
To: 'pmayer@microunity.com'; 'albers' 
Cc: 'woody'; 'howard'; 'tbe'; 'tor 1 ; 'pmayer' 
Subject: Re: Things to do list 

> From albers Thu Mar 23 08:14:03 1995 

> From: albers (Daniel Albers) 

> Subject: Re: Things to do list 

> To: pmayer@microunity.com (Patricia Mayer) 

> Date: Thu, 23 Mar 95 8:14:00 PST 

> Cc: woody (Jay Tomlinson), howard (Howard Cowles), tbe (Tom Eich), 

> tbr (Tim B. Robinson), pmayer (Patricia Mayer) 

> X-Mailer: ELM [version 2.3 PL1 1] 

> Content-Length: 820 

> 

> > the words of Patricia Mayer: 

> > 

> > Just a list of things to do for both Pandora-Euterpe and Hestia-Main: 

> > 

> > *Check the electrical/gyg conversions and edits to specifications. 

> > If we had a list of new and changed files, Howard could work on 

> > this while his database is being fixed. 

> > 

> > *Pinout for pl50__00002 is switched. 

> 
> 

> I fixed this last night. 

> 

>> 

> > *Need Pro-E to Allegro mechanical working. License? 

> 

> We have a temparary licenses which Tom and I have been using. 

> 
> 

>> 

> > * Reorder the 160pin connector. 

> > 

> > *Need global nets connected. 

> 

> Trying to work on it... 

> 
> 

> > 

> > Anything else? 

> > -Pattie 

>> 

> 

> 

> ~ 

> Daniel Albers albers@microunity.com MicroUnity Systems Engineering, Inc. 

> 255 Caspian Way, Sunnyvale, CA (408) 734-8100 

> 

> It can be made into a monster if we all pull together as a team... 

> 
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Wow, Thanks so much for the help on these items. 

Had 2 more things to add to the list 

No daughter card parts showed up on the board. 

The part p370_00009 The phone jack connector wasn't liked on the board 
because it didn't have a pin 1 . 1 changed the part and gyg files so this 
should update on the board on your next package? 

Thanks again 
-Pattie 
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From: doi (Derek Iverson) 

Sent: Friday, March 24, 1995 9:32 PM 

To: 'euterpe-checkins-dist'; Misar'; 'tor'; 'torn' 

Subject: euterpe/verify Makefile 

Update of /p/cvsroot/euterpe/verify 

In directory polyhymnia:/N/auspex2/s46/doi/chip/euterpe/verify 

Modified Files: 

Makefile 
Log Message: 

add rules to build nullTest in toplevel 
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From: doi (Derek Iverson) 

Sent: Friday, March 24, 1995 9:35 PM 

To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn' 

Subject: euterpe/verify Makefile. defs Makefile. rules Makerules. local 

Update of /p/cvsroot/euterpe/verify 

In directory polyhymnia:/N/auspex2/s46/doi/chip/euterpe/verify 

Modified Files: 

Makefile.defs Makefile. rules Makerules.local 
Log Message: 

support for building .rom files and ukernel builds (that have problems if Makerules.local is used) 
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From: doi (Derek Iverson) 

Sent: Friday, March 24, 1995 9:50 PM 

To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn' 

Subject: euterpe/verify/ukernel - New directory 

Update of /p/cvsroot/euterpe/verify/ukernel 

In directory polyhymnia:/N/auspex2/s46/doi/chip/euterpe/verify/ukemel 
Log Message: 

Directory /p/cvsroot/euterpe/veriry/ukernel added to the repository 
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From: doi (Derek Iverson) 

Sent: Friday, March 24, 1995 9:54 PM 

To: 'euterpe-checkins-dist'; 'lisar*; 'tbr'; 'torn' 

Subject: euterpe/verify/ukernel Makefile 

Update of /p/cvsroot/euterpe/verify/ukemel 

In directory polyhymnia:/N/auspex2/s46/doi/chip/euterpe/verify/ukernel 

Added Files: 

Makefile 
Log Message: 

first addition of this makefile 
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From: doi (Derek Iverson) 
Sent: Friday, March 24, 1995 10:06 PM 
To: 'euterpe-checkins-disf; 'lisar'; 'tbr'; 'torn' 
Subject: euterpe/verify/ukernel Makefile 

Update of /p/cvsroot/euterpe/verify/ukernel 

In directory polyhymnia:/N/auspex2/s46/doi/chip/euterpe/veriry/ukeme] 

Modified Files: 

Makefile 
Log Message: 

add more files to the list for the clean target 
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From: doi (Derek Iverson) 
Sent: Friday, March 24, 1 995 10:07 PM 
To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn' 
Subject: euterpe/verify Makefile 

Update of /p/cvsroot/euterpe/verify 

In directory polyhymnia:/N/auspex2/s46/doi/chip/euterpe/verify 

Modified Files: 

Makefile 
Log Message: 

break out ukernel_tests into a seperate target 
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From: billz (Bill Zuravleff) 

Sent: Saturday, March 25, 1995 12:48 AM 

To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn' 

Subject: euterpe/verilog/bsrc/nb genpim.pl nb_mid.pim nb_top.pim 

Update of /p/cvsroot/euterpe/verilog/bsrc/nb 

In directory melpomene:/N/ghidra/s2/euterpe/verilog/bsrc/nb 

Modified Files: 

genpim.pl nb mid.pim nb top. pirn 
Log Message: 

A completed placement, finally, for no-reject SN64Wibuf changes. 
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From: woody (Jay Tomlinson) 
Sent: Saturday, March 25, 1995 12:50 AM 
To: 'euterpe-checkins-dist'; 'lisar'; 'tbr'; 'torn' 
Subject: euterpe/verilog/bsrc/hc hc_ostate.pla 

Update of /p/cvsroot/euterpe/verilog/bsrc/hc 

In directory demeter;/N/auspex l/s20/woody/chip/euterpe/verilog/bsrc/hc 

Modified Files: 

hc_ostate.pla 
Log Message: 

For conflict cases, don't turn on fmclr if !req or it will hang. 
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From: billz (Bill Zuravleff) 

Sent: Saturday, March 25, 1995 12:52 AM 


Subject: Release of BOMs by billz (euterpe) 

Checkin Message: 

Passes 5woody_0 and nb_pri_13 (standalone). 
Placement is updated. 
Verification question: any problems with 
"sendNBdR3" in cbO -- that is a load, but 
not store slot? 


BOM Update in euterpe BOM 3.513 
BOM Update in euterpe/verilog BOM 3.417 
BOM Update in euterpe/ verilog/bsrc BOM 264.1 
BOM Release in euterpe/verilog/bsrc/nb BOM 1 18.0 


To: 


Cc: 


'doi'; 'lisar'; 'for'; 'torn'; 'chip' 
euterpe-checkins-dist' 
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From: billz (Bill Zuravleff) 

Sent: Saturday, March 25, 1 995 1:14 AM 

To: 'doi'; 'lisar'; 'tbr'; 'torn'; 'chip' 

Cc: 'euterpe-checkins-disf 

Subject: Release of BOMs by billz (euterpe) 

Checkin Message: 

Includes latest nb which passes 5woody_0, nb_pri_13, and 
has updated placement. 

BOM Update in euterpe BOM 3.514 
BOM Update in euterpe/verilog BOM 3.418 
BOM Release in euterpe/verilog/bsrc BOM 265.0 
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From: woody (Jay Tomlinson) 
Sent: Saturday, March 25, 1 995 1 :35 AM 
To: 'tbrybillz (Bill Zuravleff)' 
Subject: A questions from craig 

>From an implementation point of view I don't see a problem assuming that mws 
can take ltlbMiss in R5 (or It receives privLevelRl). I think it is more of a 
test/place/route issue. I assumed that the 'control bits' are from cerberus. 
Otherwise, they would be needed in R4. 
woody 

Bill Zuravleff wrote (on Fri Mar 24): 
Jay, 

Re: adding LTLB bypass control bits. 
Looks like you're the expert here; doable? 
billz 

Return-Path: <craig> 

Received: from mnemosyne.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA24836; Tue, 21 Mar 95 16:45:30 PST 
Received: bymnemosyne.microunity.com (8.6. 1 0/muse-sw.3) 

idQAA09866; Tue, 21 Mar 1995 16:45:29 -0800 
Date: Tue, 21 Mar 1995 16:45:29 -0800 
From: craig (Craig Hansen) 

Message- Id: < 1995 03220045. QAA09866@mnemosyne.microunity.com> 
To: tbr 

Subject: unpriv access to global virtual address 
Cc: billz 
Status: R 

I'm developing x86 emulation software that in order to 
access memory, needs a 48 -bit address space. Bit 47's 
special meaning confounds the problem, and my current 
plan is to use bits 63. .48 and 3 1 ..0 for x86 segment 
and offset. The current cut-down LTLB only let's be use 
bits 63. .48 when at priviledge level 2 & 3, which 
makes protecting other tasks from the emulation task 
difficult. I'd like to get the emulation task to 
run at priviledge level 0, native software to run 
at priviledge level 1 , emulation system software at level 2. 

This requires giving priv level 0 the ability to 
"bypass" the LTLB. A general capability for controlling 
this might involve 4 control bits (or perhaps 3, given 
that priv level 3 should always permit "bypass"), one 
for each priv level, controlling Itlb bypass for all 
threads (we don't need individual control per thread). 

Do we have the prospect of inserting such control 
into the Euterpe design? 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Saturday, March 25, 1995 4:37 AM 
'Kurt Wampler' 

'age (Alan Corry)'; 'billz (Bill Zuravleff)'; 'brianl (Brian Lee)'; 'dickson (Richard Dickson)'; 'geert 
(Geert Rosseel)'; 'mws (Mark Semmelmeyer)'; 'ong (Warren R. Ong)'; 'tbr (Tim B. Robinson)'; 
'torn (Tom Laidig)'; Vo (Tom Vo)'; 'wampler (Kurt Wampler)'; 'wingard (Drew Wingard)'; 'woody 
(Jay TomNnson)' 
Re: Standalone 509 route 


Kurt Wampler writes: 
wampler wrote: 


> It looks like my rip -up pass has completed this morning, and amazingly 

> enough, there are 145 disconnects! This number is very similar to the 

> 146 disconnects reported above where I tried to route just the 509 

> disconnects on a "clean slate" placement. Could be that it's the same 

> group of recalcitrant nets in both cases. I'll try to confirm that and 

> analyze why they're not routing. 

Well... the majority of nets are in common, but not all of them. 
Here 1 s 

the result of an sdiff between the two lists of sorted netnames . 

The results of both routes can be found in: 

/n/godzil la/ s2/ wampler /eurip 
/n/godzilla/s2/wampler/eu509 

The ones in common between the two lists probably need to each be looked 
at to determine the cause of failure to route. One way to do this would 
be to make a copy of the eu509/geert_euterpe-iter .df f and call it up in 
RED IT for editing and try to manually route each of the disconnects . 

That 

usually reveals fairly quickly where the problem lies. I probably won't 
get to this exercise until Monday, but if someone else wants to get a head 
start; if some of these nets look familiar; feel free to start looking and 
publish the results . 

- Kurt 

[list deleted] 
Thanks , Kurt . 

This looks like good news. If we can figure out the cause for these failures then your 
runs suggest we may be on the home stretch- certainly as far as getting a 100% route. To 
meet timing we may hvae a little more homework. 

Good work , Kurt ! 


-hopper 
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From: tbe (Tom Eich) 

Sent: Saturday, March 25, 1995 9:41 AM 

To: 'Tim B. Robinson' 

Cc: 'pmayer (Patricia Mayer}'; 'pandora' 

Subject: Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 


Tim Robinson wrote: 


> Patricia Mayer wrote (on Fri Mar 24) : 
> 

> Also, we will wait for the ProE to Allegro interface to determine 

> the 
clamp 

> area to place the caps. On all future boards we will place the 

> caps, 
say 

> 30-40 mils from the clamp? and on the secondary side. 
> 

> Any other ideas, please let us know. 
> 

> Im concerned that torn said the distance would be greater than we had 

> on hestia, and we should review this carefully once you have a 

> tentative placement. I think torn is also looking at future changes in 

> the clamping arrangement which might let us do much better on future 

> versions. 
> 

> Tim 


To be clear, it is the TAB OLB tooling that requires that the caps be further out from the 
OLB pads than in the rev 2 Hestia pcb. I hope to redesign the clamp to eliminate most of 
the keep out that is at the four corners, where the current "x" clamp design's arms are 
positioned, extending out to the four mounting holes. By freeing those spaces, I hope we 
can pull some parts back in at the corners, but I'm afraid that the TAB tooling 
requirement we violated in Hestia will mitigate much benefit. 

There are cost and size benefits to re-designing the clamp, however. The redesign of the 
clamp will not be done concurrently with the first Euterpe pcb because of the need to 
verify the design and the likelyhood of multiple iterations. The heat sink design will 
also need to be modified slightly, so for the first pcbs, we need to accomodate the X 
clamp . 

-Tom 
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From: wampler (Kurt Wampler) 

Sent: Saturday, March 25, 1995 11:18 AM 

To: 'age'; 'bilk'; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'ong'; 'for*; 'torn'; Vo'; 'wampler'; 'wingard'; 

'woody' 

Subject: Re: Standalone 509 route 


wampler wrote : 


It looks like my rip-up pass has completed this morning, and 
amazingly enough, there are 145 disconnects] This number is very 
similar to the 

146 disconnects reported above where I tried to route just the 509 
disconnects on a "clean slate" placement. Could be that it's the 
group of recalcitrant nets in both cases. I'll try to confirm that 
and analyze why they're not routing. 


Well... the majority of nets are in common, but not all of them, 
the result of an sdiff between the two lists of sorted netnames . 


Here ' s 


The results of both routes can be found in: 

/n/godzilla/s2 /wampler /eurip 
/n/godzilla/s2/wampler/eu5 0 9 

The ones in common between the two lists probably need to each be looked 
at to determine the cause of failure to route. One way to do this would 
be to make a copy of the eu5 0 9/geert_euterpe-iter . df f and call it up in 
REDIT for editing and try to manually route each of the disconnects. 
That 

usually reveals fairly quickly where the problem lies. I probably won't 
get to this exercise until Monday, but if someone else wants to get a head 
start; if some of these nets look familiar; feel free to start looking and 
publish the results . 

- Kurt 


Ripper failures 


Standalone failures 


CERB/C05/CNT03_BM 
CERB/C05/D2<3> 


CERB/C06/REDD_AM<62> 
CERB / CO 9/ EN_ANM< 3 > 
CERB/ CIO /SCRCERR0_ABNM 
CERB / CERBREQ_ABM 
CERB / KYBDVECT_ABM< 6 > 
CERB / OADDRES S _ABM< 3 1 > 
CERB/OADDRESS_ABM< 32 > 
CERB/OADDRESS_ABM< 34 > 
CERB/ OADDRESS_ABM<4 0 > 
CERB / OADDRES S_ABM< 4 1 > 
CERB/OWDATA_ABM<3> 
CERB /OWDATA_ABM< 3 5 > 
CERB /OWDATA_ABM< 4 3 > 
CERB /OWDATA_ABM< 4 7 > 
CERB / OWDATA_ABM < 4 8 > 
CERB / OWDATA__ABM< 4 9 > 
CERB / OWDAT A_ABM< 5 5 > 
CERB/SG7<16> 
CERB/SG7<2 0> 


CERB/C05/D2<3> 
CERB/ C 0 6 / REDD_AM< 0 > 
CERB / C 0 6 / REDD_AM< 1 6 > 
CERB / CO 6 / REDD_AM < 2 2 > 
CERB/C06/REDD_AM<62> 
CERB / CO 9 / EN_ANM< 3 > 
CERB/C10/S CRCERR 0_ABNM 
CERB / CERBREQ_ABM 
CERB/KYBDVECT_ABM< 6 > 
CERB /0 ADD RES S_ABM< 3 1 > 
CERB/OADDRESS_ABM< 3 2 > 
CERB/ OADDRESS_ABM< 3 4 > 
CERB / OADDRES S_ABM < 4 0 > 
CERB / OADDRES S_ABM < 4 1 > 
CERB / OWDATA_ABM< 3 > 
CERB/ OWDATA_ABM< 3 5 > 
CERB/ OWDATA_ABM< 4 3 > 
CERB/ OWDATA_ABM<4 7 > 
CERB /OWDATA_ABM< 4 8 > 
CERB/OWDATA_ABM<4 9 > 
CERB / OWDATA_ABM< 5 5 > 
CERB/SG7<16> 
CERB/SG7<20> 
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CERB/SG7<21> 

CERB/SG7<22> 

CERB/SG7<24> 

CERB/SG7<32> 

CERB/SG7<37> 

CERB/SG7<39> 

CERB/SG7<41> 

CERB/U00/B1CLR_N<5> 

CERB/UO 0 /B1XFER_N< 5 > 

CERB /UO 2 /UO 8 / AA7 13 0 

CERB/UO 2 /UO 8 / AA8 110 

CERB/U03/U07/S16 

CERB /UO 4 /Ul 0 1 0 / REGOUT_N< 4 9 > 

CERB/U04/U1010/U1100/LSCO 

CERB/U04/U1010/U112 0/LSCO 

CERB/U04/U1010/U1120/LSC1 

CERB/U04/U1010/U114 0/LSC0 

CERB/U04/U1010/U114 0/LSC1 

CERB/U04/U1010/U116 0/LSCO 

CERB/U04/U1010/U1180/LSCO 

CERB/U04/U1010/U12 0 0/LSC1 

CERB/UO 4 /Ul 010 /Ul 22 0 /LSCO 

CERB/U04/U1010/U1220/LSC1 

CERB/U04 /U101 0 /U12 6 0 /LSC1 

ES/U02/U301/Z_N 

GT/UGTSNAKE / ADDR< 2 2 > 

GT /UGTSNAKE / RQCTL 1_N 

HC1/DATAHI<14> 

HCl/PRBD00<16> 

HC1/PRBD10_N<16> 

HC 1 / PRBD 1 1_N< 1 3 > 

MC/U02/SR_FIELDTOP1_N<1> 

RG/RGPC/PCPLINCWR_N<5> 

RG/ RGRAVALURR< 3 0 > 

UU/ HIiDNB 1 OMTCHRBUS < 0 > 

XLU/ SR_RC3_6 A< 1 5 > 

CCDTAGDR15<18> 

CCNBCOUTR13_N< 7 > 

CDDINS17S2 0<123> 

CDDINS 1 7 S 2 0_N< 1 2 4 > 

CDDINS17S20_N<125> 

CDDINS17S2 0_N<126> 

CDWRTNDXH S 1 6 S 1 9_N < 1 1 :> 

CDWRTNDXHS 1 6 S 1 9_N< 1 2 > 

CECLOCKHP_ABM< 0 > 

CECLOCKHP_ABM< 1 > 

CECLOCKHP_ABM<2 > 

CECL0CKHP_ABM<3 > 

CENODE_ABM< 7 > 

CERAT IOMl_ABM< 0 > 

CERAT IOM 1_ABM< 1 > 

CERAT IOM 1_ABM< 3 > 

CERAT IOM 1_ABM< 4 > 

CEREFRESHMUIiT_ABM< 0 > 

CEREFRE SHMULT_ABM< 2 > 

CESAMPLE0FFSETP1_ABM< 4 > 

DUN_AB0PM 

FLAS HDONE _AM 

GIGVAR6R7<45> 

GTMRD<23> 

GTXRD<68> 

ISW1_V 

LTCTPAR1 2_N< 12 > 
LTNBCINR12<15> 
LTPAR12<6> 
NBHC 1 PRGRANT 
NBLDDATL 5L 6 < 1 8 > 
NBLDD ATL 5 L 6 < 1 9 > 


CERB/SG7<21> 
CERB/SG7<22> 
CERB/SG7<24> 
CERB/SG7<32> 
CERB/SG7<37> 
CERB/SG7<3 9> 
CERB/SG7<41> 


CERB/U02/U08/AA713 0 
CERB/U02/U08/AA8110 
CERB/U03/U07/S16 

CERB/U04/U1010/U1100/LSCO 
CERB/U04/U1010/U1120/LSC0 
CERB/U04/U1010/U1120/LSC1 
CERB/U04/U1010/U1140/LSCO 
CERB/U04/U1010/U1140/LSC1 
CERB/U04/U1010/U1160/LSCO 
CERB/U04 /Ul 0 1 0 /Ull 8 0 /LSCO 
CERB/U04/U1010/U1200/LSC1 
CERB/U04/U1010/U1220/LSCO 
CERB/U04/U1010/U1220/LSC1 
CERB/UO 9 /U12/LOADSRH 


CECLOCKHP_ABM< 0 > 
CECLOCKHP_ABM< 1 > 
CECLOCKHP_ABM < 2 > 
CECIiOCKHP_ABM<3 > 

CERATIOMl_ABM< 0 > 
CERATIOMl_ABM< 1 > 
CERATI0M1_ABM<3 > 
CERATI0M1_ABM<4 > 
CEREFRE SHMULT_ABM< 0 > 
CEREFRESHMULT_ABM< 2 > 
CESAMPLE0FFSETP1_ABM<4 > 
DUN ABOPM 


NBLDDATL5L6<18> 
NBLDDATL5L6<19> 
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NBLDDATL5L6<73> 

NBSTRDATS 12S15<63> 

RGIMMRAWRP_N< 1 6 > 

RGOPAR0_N<82> 

RGOPARSLTENLRQ< 1 > 

RGOPCR0_N<80> 

SA0_ABEM<7> 

SA1_ABEM<7> 

SA2_ABEM<7> 

SA3_ABEM<7> 

SA4_ABEM<7> 

SA5_ABEM<7> 

SA6_ABEM<7> 

SA7_ABEM<7> 

SB0_ABEM<7> 

SB1_ABEM<7> 

SB2_ABEM<7> 

SB3_ABEM<7> 

SB4_ABEM<7> 

SB5_ABEM< 7 > 

SB6_ABEM<7> 

SB7_ABEM<7> 

SCLKA_ABEM<7> 

SCLKB_ABEM<7> 

SCMDERR1 

SRSTRDATS 1 2 S 1 5_N< 4 1 > 

VFFSKEWBO<0> 

VFFSKEWB1<0> 

VFFSKEWB1<1> 

VFFSKEWB2<0> 

VFFSKEWB2<1> 

VFFSKEWB3<0> 

VFFSKEWB3<1> 

VFFSKEWB4<0> 

VFFSKEWB4<1> 

VFFSKEWB5<0> 

VFFSKEWB5<1> 

VFFSKEWB6<0> 

VFFSKEWB6<1> 

VFFSKEWB7<0> 

VFFSKEWB7<1> 

VFFSKEWCLKA<2> 

VRRSKEWA5<2> 

VRRSKEWB0<1> 

VRRSKEWB1<0> 

VRRSKEWB1<1> 

VRRSKEWB2<0> 

VRRSKEWB2<1> 

VRRSKEWB2<2> 

VRRSKEWB3<1> 

VRRSKEWB4<1> 

VRRSKEWB4<2> 

VRRSKEWB5<0> 

VRRSKEWB5<2> 

VRRSKEWB6<2> 

VRRSKEWB7<1> 


NBLDDATL5 L6 < 7 3 > 


SA0_ABEM<7> 

SA1_ABEM<7> 

SA2_ABEM<7> 

SA3_ABEM<7> 

SA4_ABEM<7> 

SA5_ABEM<7> 

SA6_ABEM<7> 

SA7_ABEM<7> 

SB0_ABEM<7> 

SB1_ABEM<7> 

SB2_ABEM<7> 

SB3_ABEM<7> 

SB4_ABEM<7> 

SB5_ABEM<7> 

SB6_ABEM<7> 

SB7_ABEM<7> 

SCLKA_ABEM<7> 

SCLKB_ABEM<7> 

| VFFMIN 

< 

VFFSKEWBO<0> 

VFFSKEWB1<0> 

VFFSKEWB1<1> 

VFFSKEWB2<0> 

VFFSKEWB2<1> 

VFFSKEWB3<0> 

VFFSKEWB3<1> 

VFFSKEWB4<0> 

VFFSKEWB4<1> 

VFFSKEWB5<0> 

VFFSKEWB5<1> 

VFFSKEWB6<0> 

VFFSKEWB6<1> 

VFFSKEWB7<0> 

VFFSKEWB7<1> 

VFFSKEWCLKA<2> 

VRRSKEWA5<2> 

VRRSKEWB0<1> 

VRRSKEWB1<0> 

VRRSKEWB1<1> 

VRRSKEWB2<0> 

VRRSKEWB2<1> 

VRRSKEWB2<2> 

VRRSKEWB3<1> 

VRRSKEWB4<1> 

VRRSKEWB4<2> 

VRRSKEWB5<0> 

VRRSKEWB5<2> 

VRRSKEWB6<2> 

VRRSKEWB7<1> 
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From: 


tbr 


To: 


Subject: 


Sent: 


Cc: 


Saturday, March 25, 1995 11:22 AM 
'pmayer (Patricia Mayer)' 
'albers'; 'dbulfer'; 'howard'; 'philip'; 'tbe'; 'woody' 
PCB Schedule 


Follow Up Flag: Follow up 
Flag Status: Red 

Patricia Mayer wrote (on Fri Mar 24): 
I dropped off a current schedule for PCB layout on Hestia and Pandora. 
Several questions came up; 

1) What about the Expanded Euterpe SDRAM Module? 

It's lower priority than the other boards which are essential for the 
base pandora system. However, if it looks like we would be stalled 
for any reason on any of the others we should be able to get a netlist 
together quickly. 

2) Will we need edits to the Front panel and/or the Power Supply? 

I'm not aware of anything on the front panel. I think there is 

a minor issue with the power module, but wayne was not planning to 

rev that in this turn of hestia. I'll double check that with him. 

Also, Woody suggested a schematic review for the Euterpe module. 

We had a preliminary one, but there were several changes. I think we 
should not do this until after making any edits needed to untangle the 
SDRAM interface in the new layout. 

Any other questions or comments? 


Tim 
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From: tbr 

Sent: Saturday, March 25, 1995 12:44 PM 

To: 'pmayer (Patricia Mayer)' 

Cc: 'pandora'; 'tbe@microunity.com' 

Subject: Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 
Follow Up Flag: Follow up 

Flag Status: Red 


Patricia Mayer wrote (on Fri Mar 24): 

Also, we will wait for the ProE to Allegro interface to determine the clamp 
area to place the caps. On all future boards we will place the caps, say 
30-40 mils from the clamp? and on the secondary side. 

Any other ideas, please let us know. 

Im concerned that torn said the distance would be greater than we had 
on hestia, and we should review this carefully once you have a 
tentative placement. I think torn is also looking at future changes in 
the clamping arrangement which might let us do much better on future 
versions. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Saturday, March 25, 1995 12:44 PM 
'pmayer (Patricia Mayer)' 
•pandora'; 'tbe@microunity.com' 

Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 


Patricia Mayer wrote (on Fri Mar 24) : 

Also, we will wait for the ProE to Allegro interface to determine the clamp 
area to place the caps. On all future boards we will place the caps, say 
30-40 mils from the clamp? and on the secondary side. 

Any other ideas, please let us know. 

Im concerned that torn said the distance would be greater than we had on hestia, and we 
should review this carefully once you have a tentative placement. I think torn is also 
looking at future changes in the clamping arrangement which might let us do much better on 
future versions. 


Tim 
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From: hopper (Mark Hofmann) 

Sent: Saturday, March 25, 1995 2:20 PM 

To: 'Tim B. Robinson' 

Cc: 'pmayer (Patricia Mayer)'; 'pandora'; 'tbe@microunity.com' 

Subject: Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 


Tim B. Robinson writes: 

Patricia Mayer wrote (on Fri Mar 24) : 

Also, we will wait for the ProE to Allegro interface to determine 
the clamp area to place the caps. . . . 

[snip] 

Just to make sure everyone knows: the ProE/Allegro software is installed and ready for 
use. 

thanks , 
-hopper 
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From: vanthof (vant) 

Sent: Saturday, March 25, 1995 3:56 PM 

To: Vo (Tom Vo)'; 'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)'; 'hopper 

(Mark Hofmann)' 
Cc: 'vanthof (Dave Van't Hof)' 

Subject: fullchip mnemo shorts check 


The fullchip mnemo shorts check finished this morning. I decided to let it run even 
though the short had been found to test the multi-disk option in dracula. The good news 
is that it worked just fine and only found a vss/vdd short. Yhe other shorts from a 
previous run must have been false from the multiple times the disk filled and the jpb 
died. 

The run time was not that much longer than a shorts check on euterpe which is also good. 

Tom, page me whwn a new baseplate is available and I'll start up another round of checks. 

Thanks , 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 
94089 

vanthof@microunity.com 1 408 734-8100 
"Don't blame me! I didn't vote for him" 
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From: lisar (Lisa Robinson) 

Sent: Saturday, March 25, 1995 7:37 PM 

To: 'billz' 

Cc: 'dickson'; 'jeffm'; 'mws'; 'tbr'; 'woody' 
Subject: nbfulltest 

Failed going to X on BOM 265. A couple of other tests failed too 

(hermesjateturnon and dcacheannoying). 

I have a dump on staypuft /s3/tbr/euterpe/verilog/bsrc. 

Lisa R. 
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From: woody (Jay Tomlinson) 

Sent: Saturday, March 25, 1 995 1 1 :38 PM 

To: 'tbr (Tim B. Robinson)' 

Cc: 'albers'; 'dbulfer'; 'howard'; 'philip'; 'pmayer (Patricia Mayer)'; 'tbe' 
Subject: PCB Schedule 

Tim B. Robinson wrote (on Sat Mar 25): 

Patricia Mayer wrote (on Fri Mar 24): 

Also, Woody suggested a schematic review for the Euterpe module. 

Actually this should read: Woody suggested a schematic review for the Hestia 
Main board. 

We had a preliminary one, but there were several changes. I think we 
should not do this until after making any edits needed to untangle the 
SDRAM interface in the new layout. 

Any other questions or comments? 
Tim 
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From: wampler (Kurt Wampler) 

Sent: Sunday, March 26, 1995 2:34 AM 

To: 'age'; 'billz'; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'ong'; 'tbr'; 'torn'; 'vo'; 'wampler'; 'wingard'; 

'woody' 

Subject: Re: Standalone 509 route 


I had a chance to examine the 146 or so persistent disconnects in the latest euterpe 
route. I see what's happening. Some of our non- leaf mold-generated cells have targets 
that are clashing with the Metal2 "comb" obstructions that we activate during maze & rip- 
up routing to limit the amount of Metal2 used in 3 -layer routing. The following cells 
have Metal 1 targets that fall across the routing grid line at the cell edge boundary: 


scsof 1 (dio_adOph) 
xcdecsw ( in__x) 
xcecl2citios (cout_abOpm) 
xcmux2 (dO_am) 
xcmux3 { q_am , dO_am ) 
xcnand4c (nq_am) 
xcnrlatbc (q_bm) 
xcvf f sw (out_v) 
xcvrrsw(out_v) 
xvinvc (nq_am) 


Any of these targets which fail to route during linesearch routing are prevented from 
routing during maze & rip-up because they're buried under the corab obstructions at the 
left & right cell edges. 

The preferred fix would be to move these targets one track inside the cell wherever 
possible. I'll volunteer to make the edits, but before I make a wholesale change to all 
of these cells, I'll solicit comments & objections. 

It's not easy to disable the comb obstructions in these cells because the obstructions at 
present are built into the "celltype" model which is shared by all cells with the same 
atom footprint. It's also not desirable to eliminate the comb obstructions for these 
cells, because I observe many instances where long rows of these cells are placed end-to- 
end; this would leave large horizontal runs where lengthy M2 wires could arise. 

Does anyone object to 1- track target fixes in the above cells? 


- Kurt 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Sunday, March 26, 1995 3:53 AM 
"Kurt Wampler' 

'age (Alan Cony)'; 'billz (Bill Zuravleff)'; 'brianl (Brian Lee)'; 'dickson (Richard Dickson)'; 'geert 
(Geert Rosseel) 1 ; 'mws (Mark Semmelmeyer)*; 'ong (Warren R. Ong)'; 'tbr (Tim B. Robinson)'; 
'torn (Tom Laidig)'; 'vo (Tom Vo)'; 'wampler (Kurt Wampler)'; "wingard (Drew Wingard)'; 'woody 
(Jay Tomlinson)' 
Re: Standalone 509 route 


Kurt Wampler writes : 

I had a chance to examine the 146 or so persistent disconnects in the latest 
euterpe route. I see what's happening. Some of our non- leaf mold- generated 
cells have targets that are clashing with the Metal2 "comb" 

obstructions that 

we activate during maze & rip-up routing to limit the amount of Metal2 
used in 3 -layer routing. The following cells have Metall targets that fall 
across the routing grid line at the cell edge boundary: 

scsof 1 (dio_ad0ph) 
xcdecsw(in_x) 
xcecl2cmos (cout_ab0pm) 
xcmux2 (d0_am) 
xcmux3 (q_am,d0_am) 
xcnand4c (nq_am) 
xcnrlatbc (q_bm) 
xcvf f sw(out_v) 
xcvrrsw (out_v) 
xvinvc (nq_am) 

Any of these targets which fail to route during linesearch routing are 
prevented from routing during maze & rip-up because they're buried under the 
comb obstructions at the left & right cell edges . 

The preferred fix would be to move these targets one track inside the cell 
wherever possible. I'll volunteer to make the edits, but before I make a 
wholesale change to all of these cells, I'll solicit comments & objections. 
It's not easy to disable the comb obstructions in these cells because the 
obstructions at present are built into the "cell type" model which is shared 
by all cells with the same atom footprint. It's also not desirable to 
eliminate the comb obstructions for these cells, because I observe many 
instances where long rows of these cells are placed end- to- end; this would 
leave large horizontal runs where lengthy M2 wires could arise. 

Does anyone object to 1- track target fixes in the above cells? 

Good sleuthing, Kurt. 

>From your description of the problem, I would say the one track 

>interior 

move 

sounds like a reasonable solution. I agree that we do not want to dispense with the m2 
comb obstructions. I belive we saw a noticeable improvement in routing denisty and quality 
when we created thme. Is there a way to make a local modification of some cells and verify 
that a different sort of clash is not introduced? 


-hopper 
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From: tbr 

Sent: Sunday, March 26, 1995 2:40 PM 

To: 'hopper (Mark Hofmann)' 

Cc: 'pmayer (Patricia Mayer}'; 'tbe@microunity.com' 

Subject: Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 

Follow Up Flag: Follow up 

Flag Status: Red 


Mark Hofmann wrote (on Sat Mar 25): 

Tim B. Robinson writes: 
Patricia Mayer wrote (on Fri Mar 24): 

Also, we will wait for the ProE to Allegro interface to determine 
the clamp area to place the caps.... 

[snip] 

Just to make sure everyone knows: the ProE/Allegro software is 
installed and ready for use. 

Thanks mark. I thought the problem was that dan had not yet been able 
to make it work. I know he was planning to spend time on it monday. 

Tim 
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From: tbr 

Sent: Sunday, March 26, 1995 2:41 PM 

To: 'woody (Jay Tomlinson)' 

Cc: 'albers'; 'howard'; 'philip'; 'pmayer (Patricia Mayer)'; 'toe' 

Subject: PCB Schedule 
Follow Up Flag: Follow up 

Flag Status: Red 

Jay Tomlinson wrote (on Sat Mar 25): 

Tim B. Robinson wrote (on Sat Mar 25): 

Patricia Mayer wrote (on Fri Mar 24): 

Also, Woody suggested a schematic review for the Euterpe module. 

Actually this should read: Woody suggested a schematic review for the Hestia 
Main board. 

We definitely need that. Can you schedule it please? 
Tim 
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From: tbr 

Sent: Sunday, March 26, 1 995 2:49 PM 

To: 'wampler (Kurt Wampler)' 

Cc: 'age'; 'billz'; 'brianl'; 'dickson'; 'geert'; 'hopper'; Ynws'; 'ong'; 'torn'; Vo\ 'wampler 1 ; 'wingard'; 

'woody' 

Subject: Re: Standalone 509 route 

Follow Up Flag: Follow up 
Flag Status: Red 


Kurt Wampler wrote (on Sat Mar 25): 

I had a chance to examine the 146 or so persistent disconnects in the latest 
euterpe route. I see what's happening. Some of our non-leafmold-generated 
cells have targets that are clashing with the Metal2 "comb" obstructions that 
we activate during maze & rip-up routing to limit the amount of Metal2 
used in 3-layer routing. The following cells have Metal 1 targets that fall 
across the routing grid line at the cell edge boundary: 

Great news. This is just the kind of thing we were hoping fori 

Does anyone object to 1 -track target fixes in the above cells? 

I'd say do it if we can. Presumably, since we don't have any problems 
with xb cells, there must be some rule in their generation preventing 
targets on the edge. 

It's a shame we have to make edits for the xc cells though, since they 
are all CMOS cell where to first order we are not concerned about 
performance. However, can we solve this another way? Are not the 
CMOS cells likely to have a footprint different from any ECL SOFA 
cells (beacuse of the smaller CMOS atoms)? If so. is it possible to 
eliminate the combs on these footprints without affecting anything in 
the ECL sofa? Only the scsofl is an ECL SOFA cell. 

Once we have scsofl fixed, it may make sense to remove some stuff from 
the early routing list which I think was only there to try to get 
some XLU stuff to route. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, March 26, 1995 2:49 PM 

'wampler (Kurt Wampler)' 

'age'; 'billz'; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'ong'; 'torn'; 'vo'; 'wampler'; 'wingard'; 
'woody' 

Re: Standalone 509 route 


Kurt Wampler wrote (on Sat Mar 25) : 

I had a chance to examine the 146 or so persistent disconnects in the latest 
euterpe route. I see what's happening. Some of our non- leaf mold- generated 
cells have targets that are clashing with the Metal2 "comb" 
obstructions that 

we activate during maze & rip-up routing to limit the amount of Metal2 
used in 3 -layer routing. The following cells have Metall targets that fall 
across the routing grid line at the cell edge boundary: 

Great news. This is just the kind of thing we were hoping fori 

Does anyone object to 1- track target fixes in the above cells? 

I'd say do it if we can. Presumably, since we don't have any problems with xb cells, 
there must be some rule in their generation preventing targets on the edge. 

It's a shame we have to make edits for the xc cells though, since they are all CMOS cell 
where to first order we are not concerned about performance. However, can we solve this 
another way? Are not the CMOS cells likely to have a footprint different from any ECL 
SOFA cells (beacuse of the smaller CMOS atoms)? If so. is it possible to eliminate the 
combs on these footprints without affecting anything in the ECL sofa? Only the scsofl is 
an ECL SOFA cell. 

Once we have scsofl fixed, it may make sense to remove some stuff from the early routing 
list which I think was only there to try to get some XLU stuff to route. 


Tim 
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From: Potatoe Chip [chip@rhea] 

Sent: Sunday, March 26, 1995 2:55 PM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/hc BOM 94,0 initiated by dickson completed @ Sun Mar 26 
11:54:02 PST 1995 with exit status 1.. chip 
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From: tbr 

Sent: Sunday, March 26, 1995 3:04 PM 

To: 'doi' 

Cc: 'dickson'; 'age' 

Subject: chipq 

Follow Up Flag: Follow up 

Flag Status: Red 


A process on staypuft had gone wild and had been running for a couple 
of days (it should have been a 15 min run of the router). I killed 
that process, but the .checkoutrc apparently did not exit as a result. 
I then did a 

chipq -k 4069 

to take the whole job off the Q because it has been holding off a 
bunch of other stuff. However, though that entry became marked 
'term', it still does not seem to have gone away, though I can't find 
process 3074 on staypuft. 


Seq# Target Directory 


Machine(pid) Who Stat 


1 4069 euterpe/ve^ilog^src/hc 

2 4075 euterpe/verilog/bsrc/cp 

3 4081 euterpe/verilog/bsrc 

4 4092 euterpe/verilog/bsrc/nb 

5 4093 euterpe/verilog/bsrc 

6 4103 mnemo/verilog/src/dramctrl 


staypuft(3074) dickson term 
staypuft( 15343) geert 0:03 

gamorra(8306) woody wait 
melpomene(2291) billz wait 

melpomene(4090) billz wait 
godzilla(14304) age 2:19 


It has however allowed the nect thing in line to get started. Can you 
check out the Q please? 


Tim 
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From: 


tbr 


Sent: 
To: 

Subject: 


Sunday, March 26, 1995 3:23 PM 
'lisar'; 'dickson' 

forwarded message from Craig Hansen 


Follow Up Flag: Follow up 
Flag Status: Red 


Do we now have this fully released? Has any testing been done? 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["1114" "Wed" "1" "March" "1995" "15:54:40" "-0800" "Craig Hansen" "craig " nil "26" "Re: Cerberus Node Number 
available in Exception Status Register" " A From:" nil nil "3"]) 
Return-Path: <craig> 

Received: from mnemosyne.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AAI5709; Wed, 1 Mar 95 15:54:42 PST 
Received: by mnemosyne.microunity.com (8.6.10/muse-sw.3) 

id PAA1 1209; Wed, 1 Mar 1995 15:54:40 -0800 
Message-Id: <1 995030 12354.PAA1 1209@mnemosyne.microunity.com> 
From: craig (Craig Hansen) 
To: dickson, doi, tbr 
Cc: euterpe 

Subject: Re: Cerberus Node Number available in Exception Status Register 
Date: Wed, 1 Mar 1995 15:54:40 -0800 

My earlier elaboration didn't provide for desired security 

features of the Euterpe chip. In an earlier meeting I 

verbally describe a change, which may not have seen written form. 

The rule should be: 

if the node number is 0 or 1, boot from the flash ROM. 
if the node number is 2-255, boot from Cerberus node 0. 

The flash ROM needs to be accessable via Cerberus when node==0. 
When node==l, Euterpe should be "secure," in that the contents of 
the flash ROM is not accessable via the Cerberus port. 
For 2<=node<=255, it doesn't matter whether the flash ROM 
is accessable (it likely wouldn't be present anyway). 

Additional security would result if other Cerberus registers 
are made unwritable except by Euterpe itself; this is a less 
direct method of potential attack, as all one can do via the 
Cerberus registers is set the analog levels in parts of Euterpe 
and Hermes to something marginal, and hope that some resulting 
undetected error causes a security violation. However, given 
the level of effort which has been used to thwart cable boxes 
in the past, making this impossible is probably worthwhile. 


Craig 


End of forwarded message « 
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From: chip (Potatoe Chip) 

Sent: Sunday, March 26, 1 995 5:48 PM 

To: 'geeif 

Subject: output of euterpe/verilog/bsrc/cp/.checkoutrc 


The output from euterpe/verilog/bsrc/cp/ . checkoutrc is 416k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/geert . staypuf t . 9864 . euterpe-verilog-bsrc-cp 

(which is accessible from all machines). This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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From: pmayer (Patricia Mayer) 

Sent: Monday, March 27, 1995 12:52 AM 

To: 'albers' 

Cc: 'arya'; 'rich'; 'tbr'; 'pmayer' 
Subject: Hestia Main 

Hi Dan! 

Hey, I think I've gone about as far as I can upgrading Hestia Main without 
assistance. 

I guess I'd like to see backannotated schematics... uh so I can place the caps 
around Euterpe. Also we need the pl50_00002 part updated, you mentioned this 
was done. Oh, and the daughther card "Parts", thier new and I'm sure will need 
re-packaging... 

Will you please let us know when you have preformed your magic? I'm ready 
to tackle the major rev 3 edits. 

I've commited "main7" as the allegro upgraded, but still version 2 of the 
Hestia Main. 

If I can be of any help or assitance, please let me know. 

Thanks 
-Pattie 
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From: hopper (Mark Hofmann) 

Sent: Monday, March 27, 1 995 1:33 AM 

To: 'Tim B. Robinson' 

Subject: Re: IMMINENT DECISION: SDRAMs on Euterpe side of PCB 

Tim B. Robinson writes: 

Thanks mark. I thought the problem was that dan had not yet been able 
to make it work. I know he was planning to spend time on it monday. 

Okay. I guess I may not know the latest. I'll check with Dan. 

-hopper 
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From: 
Sent: 
To: 


Subject: 


Curtis Abbott [abbott@microunity.com] 
Monday, March 27, 1995 1:46 AM 

'tony@microunity.com'; John Moussouris; Craig Hansen; 'graham@microun ity.com'; 

'h@microunity.com' 

notes on TW RF MIB 


This is intended as fodder for a meeting Tony proposes to hash out responses to the TW and 
TCI material we received last week. Since I deleted Tony's original message, I'm not sure 
I got all the recipients -- please forward to any I missed. 

I'm writing responsory material to the TCI spec as well, but that's more complex and so 
isn't as far along. 


Response to TW RF MIB: (intended as feedback we could send them. 

"we're sure you've already gotten all these comments, but we just wanted to make sure...") 

p 22. csmiModulationTypes. Missing codes 9 and 10 and nothing for straight QPSK. 
Inadvertant omission? 

p 27. svcRFChannelUselndex. Shouldn't there be an option for channels that contain both 
control and user information? 

pp 30-38. We have a number of concerns about the components of rf ChannelDescriptorEntry, 
detailed below: 

p 32. rfChannelFEC. What is the utility of knowing whether or not a channel uses FEC? 
Wouldn't it be more useful to the SMA to have some estimate of the resilience of a 
particular channel in the face of various impairments/ so that it could assign frequencies 
allocations of varying quality to more resilient channels? For example, the statistics 
table lists C/N; perhaps the channel descriptor table should list required C/N. Another 
potentially useful declaration, related to FEC, would be what length noise impulses can be 
handled error- free; still another might attempt to describe what kind of degradation is 
associated with a given gaussian and/or impulse noise level (relevant, e.g., to a link 
level error retransmit protocol) . 

p 33. We're not sure the modulation order and symbol rate parameters can be made to 
adequately describe a multi-carrier scheme like OFDM. 

Probably it can be made to work if you use a fixed modulation scheme about each carrier, 
but it seems a bit forced. 

p 33. rf ChannelDataRate . The description says this is the raw data rate computed from 
symbol rate times spectral efficiency. How about a parameter for payload rate? 

p 35. rfChannelModulationOrderRe solution. The meaning and examples are unclear. One 
normally thinks of 4 QAM (sic) , 16QAM, 64QAM, and 256QAM as being obtained by multiplying 
by 4 (i.e. by 2 in each of 2 dimensions) . The example says 16 for this case. We cannot 
extrapolate, for example, how to describe a system that can use constellations of 32 or 
128 points in addition to the above. 

p 38. r f Channel Power LevelRe solution. What does "in absolute value" mean? What are the 
units for this number? Is there a provision for systems that set power level linearly as 
well as logarithmically? 

p 49. In regards to the comments requesting suggestions, upstream channels would likely 
benefit from counters for protocol errors, collisions, other measures of contention, etc. 

p 51. rfChannelCorrectedBitErrors, etc. These are specified as counters, which will wrap 
only occasionally. It seems that they would be more useful for network management if a 
couple of time resolutions were specified: bit errors in the last minute, hour, day, etc. 

p 51. rf Channel SymbolErr or s. There are many possible communications systems designs for 


- Curtis 
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which this value cannot be reliably counted, nor is it clear to us how it adds value to 
the network manager. 

p 52. rf ChannelBlockErrors, rf ChannelCarrierToNoiseRatio . 
Multiple time resolutions might be a good idea for these too. 


A general comment: the MIB as specified allows for certain dynamic flexibility mainly 
in going between 16QAM, 64 QAM, and 2 56QAM. But if a channel modulator was agile between 
6 4 QAM, OFDM, and DSSS, there is no provision for describing that or dynamically changing 
between them. Extending the MIB to provide for this would be quite hard. The real 
question seems to be this: what is the advantage of having any flexibility within the 
"language" defined by the MIB versus using teardown and setup of channels at the channel 
configuration level? 

The latter can handle systems as flexible as you can describe, and even going between 
different QAM constellations will clearly require something like connection teardown and 
re -establishment at the receivers. To couch this comment as a suggestion: why not 
simplify the MIB by removing the modulation order change stuff? (The power level part is 
not subject to the same comment, and should stay.) 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Monday, March 27, 1995 10:18 AM 

Vant' 

'wampler (Kurt Wampler)'; 'torn (Tom Laidig)'; 'geert (Geert Rosseel)'; Vanthof (Dave Van't 
Hof)'; 'vo (Tom Vo)'; 'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)' 
Re: notch filling in mnemo and euterpe 


vant writes: 
Hello, 

The remaining notch drc errors in the mnemo and euterpe databases are from 
autogenerated tools. All custom notches have been filled. Thus I'd like 
to propose the following: 

- add notch filling on a per chunk basis. This reduces the number 
of notch errors and in fact, for both mnemo and euterpe, this 
should eliminate all notches. 

By running the notch filler on each chunk, vlsimm runs on a much 

smaller dataset, and for chunks which have no violations, it runs 
very quick. In addition, since we know the data coming out 
of gards is 'on-grid', the step size for notch filling can be 
increased from 1 to 10 udrs, decreasing runtime by lOx. 

- add notch filling before fracturing to catch any notchs created at 
chunk boundaries. I have not noticed any of these, so for mnemo and 
euterpe, I believe this will run in the time it takes to do the notch 
check, which is only a fwe hours. 

We are very close to finished up both chips and if we could remove the notch 
false errors from the metals drc, I'd be very happy. 

Good. I think this is reasonable proposal. We'll still run DRC's at the back-end (after 
fracture) to make sure we flag any notches that slip through. 

(But what you are porposing should be the fastest way of f illingnotches and has the 
benefit that the first pass DRC will be almost, if not fully, notch-DRC clean.) 


-hopper 
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Subject: 


From: 


Sent: 
To: 

Cc: 


hopper (Mark Hofmann) 

Monday, March 27, 1995 10:25 AM 

'geert (Geert Rosseel)' 

'bpw (B. P. Wong)'; 'wampler (Kurt Wampler)'; 'tbr (Tim B. Robinson)'; Vant' 
phi a/b flipped identified on Euterpe 


Kurt and I had another look at the phi a/b flip this afternoon in the gtlb area. The 
problem turns out to be in the hookup of the gtlb to the phi a/b clock spars inside the 
cell crclkintll . ly- which is only used by the gtlb. 

Kurt has just completed the edits to this cell. It has been locked down and released. 
Tim, could you do a getbom in the Euterpe snapshot area? 

Then Dave can launch another LVS and, if we're lucky and we haven't introduced a metal 4 
short, we'll be able to re-verify without a new Gards re-route. 

If this is clean, then when Kurt's patches to the XC cells are checked in we'll soon be 
in good shape to run a full chip Euterpe LVS (after we get a completed route that is) . 


- thanks , 
hopper 
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Sent: 
To: 

Cc: 


Subject: 


From: 


vanthof (vant) 

Monday, March 27, 1995 12:40 PM 

'two (Fred Obermeier)'; 'rich (Rich McCauley)' 

'vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'geert (Geert Rosseel)'; 'mudge (john 
mudge)' 

VPP power pads in euterpe 


Hello, 


I'm trying to generate a special layout cell for mudge which extracts out all the Metal 5 
pads and node names associated with them. I'm almost done and am a bit confused about 
some signals from the pll section. In particular, the VPP pads. These are labeled at the 
top level of the pll blocks as VPP. The layout cells are 1 custom_vdda_pads ' and at one 
point they were treated special in the space transformer generation. These pads are _not_ 

labeled at the top level of euterpe which means that fullchip netlists don't see these as 
anything special. I was also under the impression that 

only vdd and vss pads were allowed to be internal to the pad ring. 

Are these VPP pads wired up special? and if so, how are they handled in the netlist and 
also how are they handled with the space transformer? 

Any clarification would help tremendously as I'm also going to be running fullchip lvs on 
euterpe soon. 


Thanks , 
Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 
94089 

vanthof@microunity.com 1 4 08 734-8100 
"Don't blame me! I didn't vote for him" 
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Subject: 


Sent: 
To: 

Cc: 


From: 


rich (Rich McCauley) 

Monday, March 27, 1995 1:44 PM 

'two 1 ; Vanthof 

'hopper'; 'geert'; 'mudge' 

Re: VPP power pads in euterpe 


The requirement for these pads is that they share no common current with the rest of the 
chip until tying into the PCB power plane. There is one pad for each of the two PLLs 
which are to be separately bypassed with beads/ inductor/capacitors on the board before 
being tied into the 3 . 3v power plane. 

Currently they are called out as 'vddepO and vddepl 1 in the verilog for euterpe. 

They should be named in the verilog and texted in the layout with something consistent 

with verifying them as separate pads not connected to vdde on the chip. If the name 

' vddep*' doesn't permit this due to some global combining of all signals starting with 

•vdde', then this need to be changed. I believe that the analog pads on calliope were all 

labeled 'vpp*' at the top level. 


> From vanthof Mon Mar 27 09:39:35 1995 

> From: vanthof (vant) 

> Subject: VPP power pads in euterpe 

> To: fwo (Fred Obermeier) , rich {Rich McCauley) 

> Date: Mon, 27 Mar 95 9:39:32 PST 

> Cc: vanthof (Dave Van't Hof ) , hopper (Mark Hofmann) , geert (Geert 
Rosseel) , 

> mudge (john mudge) 

> X-Mailer: ELM [version 2.3 PL11] 

> Content- Length: 1102 


> Hello, 

> I'm trying to generate a special layout cell for mudge which extracts 
out all 

> the Metal 5 pads and node names associated with them. I'm almost done 
and 

> am a bit confused about some signals from the pll section. In 
particular, 

> the VPP pads. These are labeled at the top level of the pll blocks as 

> vpp. The layout cells are ' custom_vdda_pads 1 and at one point they 

> were 

> treated special in the space transformer generation. These pads are 
_not_ 

> labeled at the top level of euterpe which means that fullchip netlists 

> don't see these as anything special. I was also under the impression 
that 

> only vdd and vss pads were allowed to be internal to the pad ring. 
> 

> Are these VPP pads wired up special? and if so, how are they handled 

> in 
the 

> net list and also how are they handled with the space transformer? 
> 

> Any clarification would help tremendously as I'm also going to be 
running 

> fullchip lvs on euterpe soon. 


> Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, 
CA 94089 


rich 


> 


> Thanks, 

> Dave 


> 
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> vanthof@microunity.com 1 408 734-8100 

> "Don't blame me! I didn't vote for him" 
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From: Gregg Kellogg [gregg@hts.microunity.com] 

Sent: Monday, March 27, 1995 1:53 PM 

To: 'richard@bluestar.com' 

Subject: (Fwd) (Fwd) Disk Arrays for Digital Video 


I finally dug up the message that I tried to send to you before. 

How are things going? I finally got ray system set up, although it's not on the net yet 
I went ahead and followed the flow to get a high-end Pentium system. 

With Fast/Wide SCSI systems becoming more available, this might make a nice system for 
doing video work in the future. It's also nice to be able to run Linux on the box. It 
gives me the illusion have having a bit more control. 

I hope this information (as out of date as it is) might be of some interest to you. 
Gregg 

Forwarded mail from <gregg@hts . microunity . com> ("Gregg Kellogg") 

To: rnewton@ic.eecs.berkeley.edu 


Forwarded mail from <gregg@hts .microunity . com> ("Gregg Kellogg") 

To : newton@eecs . berkeley.edu 
Richard, 

I thought you would find this interesting as I recall you describing your experiences 
trying to get your PowerMac to do video well. 

Gregg 


Date: Thu, 12 Jan 1995 15:48:19 -0500 
From: boykin@gte.com (Joseph Boykin) 
To : digvid- l@ucdavi s . edu 

Subject: Experiences building a Disk Array for Digital Video 
Message-ID: <ab3b44d60c0210047f 97® [132 . 197 . 14 . 175] > 

I have been asked by a number of people to summarize ray experiences putting together a 
RAID subsystem for use with digital video. This is a report on those experiences. It is 
longer than expected, but I have tried to write down a lot of what I have uncovered over 
the past six months. It also tries to explain some of the matters that must be considered 
when putting such a system together. For example, *why* were the sustained data rates of 
3.5MB/s, 5.5MB/S and 6.5MB/s of interest to me? Read on and find out. 

First, let me give some background. I do not do digital video professionally, it is 
purely a hobby, but I'm what you would call a "serious hobbyist". I have been doing video 
for a number of years, with my primary material source being underwater video (I'm a PADI 
& SSI instructor and teach courses in U/W video if anyone is interested!) I did my 
editing on a SONY EVO-9700, but there aren't any whiz-bang features in that deck, e.g. no 
transitions, and I prefer playing with digital over analog technology anyway. 

My end-goal is full-frame, full-motion NTSC video on the order of 5-15 minutes. I'd love 
S-VHS/Hi8 quality, but I don't want anything less than VHS quality. Even if my final work 
will be output to VHS quality tape, I want to keep my edits in as high a quality as 
possible. In other words, I want to be able to hand a tape to someone and have them see 
it on a TV and not just produce little 160x120 clips for CD-ROMs. 

Being a "do it yourselfer" at heart, I put together a system with a Quadra 840AV, Radius 
VideoVision Studio, and a RAID array. This document talks about my experiences getting 
that RAID array going and the ancillary things that went along with it . . 
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Looking at the prices for pre-conf igured arrays, I decided to put one together myself. 
After all, how hard could it be? To answer that question in advance: I started this in 
June and I finished in January. 

I started with two Micropolis 22 3 6AVs (3GB each) . These drives had reasonable capacity, 
reasonable speed and boasted dealing with Thermal Recalibration (TCal) well. Other than 
the fact that these drives a) consume a lot of power and b) run pretty hot, they are 
probably excellent for many applications. However, I ran into a serious problem; they 
don't stripe well. I put the drives on the same SCSI chain and was surprised to find that 
I only achieved about a 5% performance increase when striped. 

About 25% is more typical for RAID level 0. I eventually learned that these drives do not 
handle SCSI-2 disconnect /reconnect well (or maybe at all) . If the drives were on separate 
SCSI chains, this wouldn't be a problem. Given that they were on a single chain, the 
ability to do disconnect/ reconnect is required. OK, back to the drawing board. 

While Micropolis makes a big deal of their AV drives, in reality, many new drives handle 
TCal fairly well. The manufacturers know that the newest large capacity and fast drives 
are going to be used in digital video, so they are trying to ensure their drives work well 
for this demanding 

environment. They do TCal less often and postpone TCal if a read or 
write 

operation is pended. What that means is that a new non-AV drive may do just fine for you 
(especially if your disk housing has good cooling) . 

Drives from both Micropolis and Seagate are the top picks in this category. 
Fujitsu and Conner also have mechanisms . that work well, but you need to be sure about a 
♦particular* mechanism before you buy it . You can guarantee yourself that any old drives 
or new drives that aren't at the top of the curve will not handle TCal well. Based on 
that, I chose four Seagate Barracuda 4's as my disks. The drives are big (4GB each) and 
fast (7200 RPM, 8ms seek, 1MB cache) and yes, they do postpone TCal. More on the drives 
later . 

Next: the hunt for a SCSI accelerator. There are several out on the market, but based on 
other people's experience in terms of both performance and reliability I narrowed down my 
choice to the ATTO and FWB cards. ATTO has a Silicon Express II Fast SCSI-2 card and a 
Silicon Express IV Fast/Wide card. Street prices are $725 and $990 respectively. FWB has 
their SCSI JackHammer card which supports Fast/Wide transfers at a street price of about 
$700. Rumor had it that the ATTO card was a bit faster, so I chose the ATTO SE II (I had 
bought "narrow" drives) . My logic was 

simple: with a RAID array and an accelerator, I probably would have enough performance for 
what I want. You'll see shortly that I was wrong. 

The card arrived long before the disks, so I couldn't test things out immediately. By the 
time I did, the card was about 2 months old and turned out to be flaky (the system would 
hang when I tried to do any significant amount of I/O to drives attached to the card) . I 
contacted ProDirect, who I purchased the card from, and their Tech support folks told me 
they didn't even have a system they could test it out on and, since the card was two 
months old, they wouldn't swap it for a new one anyway. I turned to ATTO, who preferred 
that I deal with ProDirect, since that is who sold it to me, but after telling them what 
PD said, they relented. I sent them my card and was pretty quickly told that "it worked 
for them" and it was returned to me . I was pissed. I tried the card in three systems (2 
84 0s and an 

800) again, with the same results. I returned the card to ATTO who still couldn't find 

anything wrong with it, but agreed to swap it for a new one. 

The new card arrived and works well (at least, it didn't crash my system) . 

At this point, I started running a bunch of performance tests. I have three formatting 
utilities: FWB HDT VI. 6, Transof t ' s SCSI Director Pro V3.07, and CharisMac's Anubis 
utility V2.52S (I've recently upgraded this to version 2.53 with PowerControl (lets you 
control mode page settings) and RAID software, but I have not used those features yet. 
NOTE: I have been told that the CharisMac RAID software is *not* very good in its current 
release) . I reformatted one drive with each of these and ran FWB • s BenchTest and ATTOs 
performance utilities to see what I got. A short version of my results: Partition size 
doesn't matter (except that the FWB benchmark test thinks smaller partitions are faster), 
under System 7.5 cache size doesn't matter, and the FWB driver did pretty poorly. 

Test configuration: Q840AV w/80MB memory; System 7.5. Partition size was 2GB. Using the 
internal SCSI Bus I achieved: 
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Driver 


Sustained Read Sustained Write 


FWB 

CharisMac 
Transof t 


2 . 8MB/s 
3 . OMB/s 
3 . OMB/s 


3 . 2MB/ s 
3 .6MB/S 
3 .6MB/S 


As you can see, if you are using the internal SCSI bus the CharisMac and Transof t drivers 
were about the same with the FWB driver falling significantly behind. I don't know why; 
perhaps it is the driver itself, perhaps it was some mode page (the disk drive's firmware 
parameters) settings that the formatter set. My belief is that it is a combination of the 
two as an e.g. Transof t driver on an FWB formatted drive is faster than an FWB formatted 
drive with the FWB driver . I never looked into it enough to narrow down the cause any 
further. (It takes a *LONG* time to run these tests and since I didn't have to know why 
one was faster than another, I just cared which was faster there's a point where this 
being a hobby is an advantage!) 

While these are interesting numbers (and caused me to reformat and initialize all the 
other drives I had access to at home and at work with the Transof t driver!), for eventual 
use on an accelerator card it didn't matter. When a drive attached to the ATTO card is 
mounted you use a driver that is in the ATTO firmware. The same is true for the FWB card 
and any of the current crop of SCSI accelerator cards. The performance data was obtained, 
and were of interest, because they provide a baseline of comparison. 

I moved the drives back to the ATTO card and went to install the RAID software. I have 
both the ATTO ExpressStripe software and Trillium Research's Remus Limited, I started 
with the ATTO software (version 2.00) but the system crashed as the INIT was being loaded. 
ATTO gave me a free upgrade to 2.01 (tech support created an account on their system and 
let me dial- in via ARA to download the file, very nice of them), but that didn't work 
either. ATTO then gave me a Beta copy of their 3.0 software and that did work (and is 
much nicer to use) . ATTO Tech support didn't know why 2 . OX didn't work, but at that 
point, I didn't really care. 

Reliability of the 3.00 software wasn't very good (what do you want from Beta software?!?) 
Occasionally, the drives would become inaccessible. 

While ATTO was figuring this out, I switched to the Remus software which has an even nicer 
interface. 

Using the Remus software, I tried various configurations. I tried: 
striping across two, three and four drives 

changing the allocation unit anywhere between 16K per drive to 64 K 

varied the logical file system size between 256MB and 4GB 

varied the size of the system buffer cache. 

My peak performance was approximately 5,2MB/s sustained read and 4 . 5MB/ s sustained write. 
This surprises me. I would have expected writes to be faster (you can do "blind writes" 
and return control to the application before the actual write completes) . The WS 
software that "find"s throughput reports about 2.8MB/s from within Premiere V4 . 0 using QT 
2.0. 

These results were achieved using a 64K chunk across either 3 or 4 drives (the numbers 
were close enough the difference doesn't matter), with a 1GB file system. I have heard 
that striping across three drives is faster than across four, but I didn't see that. 
Note: The FWB benchmark tests generally show smaller partitions as having better 
performance. The reason for this (I think) is that their random write tests have to move 
the disk heads less, thus reducing seek times. Sustained transfer rate, the number of 
interest in digital video capture, was the same regardless of partition size. I consider 
the effect of partition size to be an artifact of the benchmark and not a real factor in 
performance. 

I was disappointed with the results as my "dream" was to get about 6.5MB/s through to the 
application. To do full- frame (640x480) full-motion (60 

fields/sec) VHS quality video takes somewhere around 3MB/s if you have a reasonably clean 
signal. With a "great" signal, this could drop even further. Both my Sony EVO 97 0 0 and 
camcorder have S-video in/out (S-video has the video signal split into two separate 


Exhibit C12 


Page 514 of 643 


signals "luminance" and "chrominance", plus separate lines for audio), so the signal is 
pretty good. (RGBS (Separate Red/Blue/Green/Sync) signals would be cleaner, but no 
consumer, and few "pro-sumer" equipment has them, RF connections (all audio and video 
signals combined onto one cable-typical for consumer gear) would be the worst and hence 
require more bandwidth for the same level of quality. 

If I want S-VHS quality I'd need about 5.5MB/s. My goal of 6.5MB/s gives me a little 
extra so that if a random TCal hits, or the drive needs to retry an I/O, I should be able 
to survive it. I doubt if I will actually capture at 6.5--the difference between 5.5 and 
6.5 is generally not visible, even to an experienced eye. Of course, if I'm digitizing 
images with a lot of detail, and hence do not compress well, that extra throughput would 
come in handy. 

So, my 2.8MB/s was disappointing. I would have been satisfied if I had 3.5MB/s as then I 
could have done VHS+ quality and been happy enough, but with 2.5 that was not possible, 
and S-VHS quality was totally out of the question. 

Now what? If you missed it, I chose the ATTO Silicon Express II card and Fast SCSI-2 
drives. That was the mistake. Thinking that those drives could do lOMB/s I figured that, 
when striped and with an accelerator card, I wouldn't have too much problem meeting my 
3.5MB/s minimums. I was wrong. 

I went back to the folks I bought the drives from, Direct Connections, and they agreed to 
take back the drives and sell me four Fast/Wide Barracuda 4's. They gave me a 100% credit 
on everything I bought! It wound up costing a "few bucks" to make the switch (wide drives 
are more expensive), but it wasn't that bad. I had to do a little arm twisting there, but 
DC was * superb* when it came to handling this problem. without any question, I can 
endorse people buying from them. (Tell Dave I said Hi) . 

Now for the accelerator card. I needed to swap the SE II for an SE IV. I went back to 
ProDirect, told them my sob story, etc. and they basically hung up on me. Even though 
they sold me a flaky card, they couldn't/wouldn't even attempt to deal with the problem, 
and most importantly, ATTO was willing to do just about anything to convince them they 
should do this (e.g. provide new packaging, certify the card was OK, 

etc) they wanted to have nothing to do with me. From a pure business standpoint I can't 
really blame them. After all, the card was five months old at this point (even though I 
only had a working system for about two weeks) , from a customer satisfaction stand point, 
and from the standpoint of having nothing to lose (ATTO was willing to stand behind the 
"used" 

card), and I was going to buy the more expensive SE-IV, they didn't even want to consider 
it. More than the fact that they wouldn't help, it was their attitude that was bad, and 
for that reason, I have no intentions of going back to ProDirect again. 

When Direct Connections shipped the four fast/wide Barracuda 4's, I also bought a Silicon 
Express IV card from them. That leaves me with a Silicon Express II to sell, so if anyone 
wants it, I currently have an SE-II that I'm looking to sell. A good card, just not what 
I needed. 

Anyway, I put the system together and began running some tests. 

Performance was * significantly* better (I should hope so!). Using Remus Limited RAID 
level 0 software and FWB BenchTest to measure performance, I achieve the following: 

Configuration Sustained Read (MB/s) Sustained Write (MB/s) 


Single drive: 5.4 9.3 

Two drives: 8.4 13.3 

Three drives : 8.9 13 . 3 

Four drives: 9.4 13.2 

FWB (2 drives) : 8.2 9.2 


All tests were done on a Q840AV running System 7.5, numerous INITs (I fill the bottom of 
the screen on startup) , and four fast /wide Barracuda 4s (ST15150W) . I chose to benchmarks 
with all INITs enabled as that would be my execution environment, rather than a minimal 
system (although I turn AppleTalk off, don't use a screensaver, etc). I prefer "real 
world" 

scenarios. However, I ran a subset of the benchmarks with most INITs disabled (I still 
needed QuickTime, WS, Remus and the like) and found that there was no significant 
difference in performance results (it was slightly faster without the INITs, but not by 
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enough to mean anything). This surprised me, but I'm not complaining, I haven't tested 
the performance with and without INITs with the WS "find" command, but I would expect 
that there would be a slight hit. 

Except for the last test, all drives were connected to an ATTO SiliconExpress IV card with 
V9 PAL and Version 1.4 firmware. The partitions were all 2GB logical partition and were 
the first partition on the disk (additional partitions are generally slower) . The final 
number was using an FWB SCSI JackHammer card and FWBs RAID Toolkit software . 
Remus is supposed to work with the FWB card, but I could not get it to do so. As the FWB 
card was borrowed from a friend, I did not have the time to diagnose the problem. This 
test was done using two drives {the most the FWB software supports) . Note: One strange 
problem was found with the FWB 

card: when that card was installed, my system would not boot from my standard startup 
disk. Instead, it always went to a backup system folder I keep on a different drive. 
Once the system was up I could manually mount the other partition. Strange. 

Why is read performance so much less than write? I believe the answer has to do with both 
the ATTO hardware and Remus software, although I haven't looked into it enough to find 
out. My guess is that, between the two, they are simply buffering write requests and 
immediately returning control to the application prior to the write taking place, never 
mind actually completing. The result Is high (and fairly constant) write throughput) . 

The configuration I am using has four 4GB partitions striped across four drives. Using 
four drives has several advantages and disadvantages. 

Additional drives help read performance. As each drive has a 1MB cache, if I only access 
one partition at a time, I effectively quadruple my on-board disk cache. How much that is 
also helping read performance I cannot estimate, but the end result is the same. in 
addition, the large per- drive cache also helps in dealing with TCal--the drive controller 
can buffer data while the mechanism is unavailable during TCal . The downside is that with 
more drives there is a higher probability of failure. In addition, if I lose one drive I 
lose 16GB of data. For many, that could be enough reason to stay away from this 
configuration! On the other hand, for myself, I am not concerned about the loss. First, 
as I've said before, this is a hobby; the world will not end for me if I get set back a 
little. Second, I have two 8mra Exabyte tape drives on my system and do automated nightly 
backups with Retrospect. Even with a catastrophic failure, I won't lose much. 
I'm 

a big believer in backups ! 

The Radius VideoVision Studio "find" command reports about 5.8MB/s (5.9 without audio) 
through to Premiere. Slightly less than my optimal 6.5, but more than the 5.5 I really 
needed for S-VHS quality. At this point, I'm happy and am capturing and editing full- 
motion, full-frame video and the fish are gorgeous! 

Effect of partition size: as in the past, I see a significant difference in FWB ' s overall 
index of performance based on partition size. The larger the partition, the worse the 
rated performance. Again, I consider this to be an artifact of the benchmark test, not a 
true measure. Regardless, for digital video my interest is in sustained transfer rate. 
Even if the performance is worse with larger partitions, my measurements show no 
difference in sustained transfer rate as a function of partition size. 

Effect of buffer cache: I am currently using System 7.5. Apple made some significant 
changes to their disk buffer cache algorithms in this release. 

Previously, a larger buffer cache would not help performance and, .especially for digital 
video, could hurt performance. I ran the same tests using buffer cache sizes of 32KB, 
192KB, 1MB and 2MB and found no significant difference between them. 

I've seen 17MB/s in ads, why aren't these numbers even close?: 

Several RAID vendors advertise about 17MB/s in their ads. They do so by using *two* SCSI 
accelerator cards. For most systems, using two SCSI channels doesn't buy you much. I've 
traded benchmark numbers with several people using Seagate Barracuda drives on 8100/80 »s 
{which has two SCSI 

busses) and their performance is about the same as mine using a single bus. 
However, when using an 840AV (which has a very fast NuBus) , dual SCSI channels can help-- 
in fact, if the numbers are accurate, it looks like it helps to the tune of about 30% (and 
about $1, 000 I ) . 

That's the good news. The bad news is that these are not real-world benchmark numbers. 
My bet is that the NuBus and CPU are saturated at that point and not much else is going to 
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go on. Given that the goal of all that throughput is to capture and play back video, when 
another NuBus card like the WS is also sitting on the bus, your actual throughput may go 
*down* . 

This is because there is too much bus contention, and limited bus perormance. I recently 
had the opportunity to demonstrate this to an acguintance who had such a setup- -to say the 
least, he was surprised that his very expensive RAID array was hurting rather than helping 
him! He pulled the second NuBus card and we started capturing video with fewer dropped 
frames and more throughput. This may be counter- intuitive until you realize that you 
these cards are using "more than their fair share" of a very limited resource. Note that 
using multiple SCSI accelerators will work a lot better when we have faster busses (e.g. 
PCI) and faster CPUs. 


Acknowledgements and comments about vendors : 

ATTO: ATTO was pretty amazing. I think those guys are triple jointed because they bent 
over backwards for me in more ways than I could count. 

They were there at every step of the way, doing everything possible to both make my system 
work and, more importantly, their attitude was right. When my SE-IV had some funny 
symptoms, they volunteered to have me just ship the entire system, on their nickel, to 
them and they would take a look at it from there. The comment from ATTO was "you've been 
at this too long with too many problems, let's fix it." These guys, and in particular, 
Mike Woltz in tech support, are champs. 

Radius: Mike Jennings of Radius's digital video team, and one of the people who has been 
pulling *his* hair out over at Radius to make disk arrays work well in the digital video 
world and I have had numerous email exchanges on this topic. while I may be the owner of 
a WS, his advice and comments on my efforts have gone well beyond what one would expect 
from an engineer at such a company. His comments on this document (he proofread several 
pre-releases) have also been invaluable. Indeed, the notes on throughput requirements for 
various video quality and signal conditions are mostly his. 

Direct Connections: As I said previously, these folks have been very cooperative and 
willing to help. I haven't received, and didn't ] the type of technical support I received 
from ATTO and Radius, but they have been great to work with. If you need peripherals, I 
heartily recommend them. 

ProDirect: A good place to avoid. I'm sure many will reply saying how they had great 
experiences with ProDirect- -that is always true, some people have good and some have bad 
experiences with vendors. My experiences were uniformly bad. When ATTO tried to help, 
they didn't return ATTOs phone calls. It seems to me this is a place to avoid. 

Final note: What is described in this document is based on my own experiences. While I 
have received help from many corners, I have not stated anything that I have not directy 
experimented with and discovered myself. The errors are therefore exclusively my own. As 
I have done this work on my own time, with my own (or borrowed) hardware and software, 
this document does not represent opinions of, and is not endorsed by, my employer. I do 
not guarantee that you will have the same, or even similar results. 

This has been an interesting exercise. I hope to expand upon it if and when additional 
hardware and software become available to me. If so, I will announce the results and, 
eventually, make this information available electronically. 


Joseph Boykin 

Principal Investigator 

Distributed Computing Systems 
GTE Laboratories, Inc. 

First Vice-President 

IEEE Computer Society 

Email : j . boykin@computer . org 


End of forwarded mail from <gregg@hts .microunity . com> ("Gregg 

Kellogg") 
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Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg@microunity.com 


End of forwarded mail from <gregg@hts .microunity . com> ("Gregg 

Kellogg") 
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From: vanthof (vant) 

Sent: Monday, March 27, 1995 1:56 PM 

To: 'Rich McCauley' 

Cc: 'fwo (Fred Obermeier)'; 'hopper (Mark Hofmann)'; 'geert (Geert Rosseel)'; 'mudge (john 

mudge)'; Vanthof (Dave Van't Hof)' 
Subject: Re: VPP power pads in euterpe 


Rich McCauley writes: 
> 

>The requirement for these pads is that they share no common current 

>with 

the 

>rest of the chip until tying into the PCB power plane. There is one 
>pad for each of the two PLLs which are to be separately bypassed with 
>beads/ inductor/capacitors on the board before being tied into the 3 . 3v 
>power 
plane. 

>Currently they are called out as 'vddepO and vddepl ' in the verilog for 
euterpe . 

>They should be named in the verilog and texted in the layout with 
something 

>consistent with verifying them as separate pads not connected to vdde 

>on 

the 

>chip. If the name 'vddep*' doesn't permit this due to some global 
combining 

>of all signals starting with 'vdde', then this need to be changed. I 
believe 

>that the analog pads on calliope were all labeled 'vpp*» at the top 

level . 

> 

>rich 


Thanks Rich, 

I've have run into vddep* for lvsing the 'small' euterpe and have a 
fix for that. Thanks for stopping by and helping out with the vpp pads. 

Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 
94089 

vanthof@microunity.com 1 408 734-8100 
"Don't blame me! I didn't vote for him" 


Exhibit C12 


Page 519 of 643 


Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Eich [tbe@microunity.com] 
Monday, March 27, 1995 4:29 PM 
'craig (Craig Hansen)' 
'abbott'; 'graham'; 'h'; 'tbr* 
Re: Latest TCI spec 


>The "fan ban" in the specification is disturbing, but I don't think it 

>takes us out of the picture. There are at least three 

>mutually- inclusive ways to respond to the fan-ban in the TCI Digital 

> Terminal preliminary specification: 

> 

>1) [meet the stated intent of the specification] 

> The fan-ban appears in a section which is concerned with the safety of 

> heated surfaces in the physical packaging. Our chips have temperature 

> sensing mechanisms that detect over temperature and permit shutdown of 

> the system, and which force shutdown at a certain point. This shutdown 

> mechanism could be used to demonstrate that fan failure doesn't cause 

> any surface to get hotter than the specification. 


The specification clearly states that the surface temperature limits of UL 1409, para 46 
must be met with the "converter "on" and after temperature is stabilized". Thermal 
runaway, which would ensue after fan failure , is hardly a stable condition. Anyway, given 
the surface temperatures we measured with the fan operating, there is insufficient margin 
to maintain the UL limits during a fan failure prior to overtemperature shut-down. 

How do you read that the stated intent of the specification is to meet UL safety limits, 
including the post- fan failure case, with the result of that failure being a unit shut- 
down? . The inference I drew from this spec is that in either normal or at worst sleep 
mode, the surface temperature limits must be met without a fan. We do not comply for 
either case with the current design, and I'd bet lots that TCI means functioning when they 
say "on" in this spec. 

>2) [get the specification changed] 

> in addition to the fan- ban, there are many other aspects of the 
>specif ication 

> that depend upon GI specifications for functionality. This clearly 

> suggests that GI has been exerting control on the specification, and 

> to the extent possible, we should attempt to do so as well. Getting 
the 

> fan-ban removed should be one of those attempts. 


It does not address the cost of delivering and taking away the 220+ Watts. 
It looks like GI 1 s design is about 4 times lower in power, from what I hear. 

>3) [improve our design] 

> Our current design is only our first attempt, one for which the 

> demonstation of functionality is paramount over issues of cooling, 

> size, weight, appearance and cost. In all likelyhood, this box 

> would be used in trial quantities, and volume shipments will 

> employ improved designs. Future chip designs will provide 

> for the lowering of power and cooling requirements. 


If size, weight, appearance and cost had been given a lower priority over demonstration of 
functionality, then we might have had a Hestia that had sufficient thermal margin to deal 
with the -5 0% unit power increase we eventually experienced, as well as easier access to 
debug the circuits and lower acoustic noise. What we have now, I regret to say, is really 
the design for Euterpe at knob setting 4, which makes no sense given the mission of the 


> 


> Regards , 
>Craig 


unit. 
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I can not imagine demo 1 ing the unit to customers and not getting a lot of questions about 
noise, reliability, and how we plan to cost-reduce. I doubt that the small size will 
mitigate these concerns. Pandora seems to me a better demonstrator anyway, in that is is 
configurable and expandable. 

The current Hestia product design, when it eventually functions, will really be more of a 
functional appearance model, and at the projected power levels, not suitable for any 
deployment, even trials (I keep hearing the word trials with respect to the current 
design) . I'm repeating myself here, but it seems to be necessary. 

-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94 08 9 
(408)734-8100, (408)734-8136 fax 


tbe@microunity . com 
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From: vanthof (vant) 

Sent: Monday, March 27, 1995 5:49 PM 

To: 'wampler (Kurt Wampler)'; 'torn (Tom Laidig)'; 'geert (Geert Rosseel)'; 'hopper (Mark 

Hofmann)' 

Cc: 'vanthof (Dave Van't Hof)'; 'vo (Tom Vo)'; 'tbr (Tim B. Robinson)'; 'lisar (Lisa Robinson)' 

Subject: notch filling in mnemo and euterpe 


Hello, 

The remaining notch drc errors in the mnemo and euterpe databases are from autogenerated 
tools. All custom notches have been filled. Thus I'd like to propose the following: 

- add notch filling on a per chunk basis. This reduces the number 
of notch errors and in fact, for both mnemo and euterpe, this 
should eliminate all notches. 


By running the notch filler on each chunk, vlsimm runs on a much 

smaller dataset, and for chunks which have no violations, it runs 
very quick. In addition, since we know the data coming out 
of gards is 'on-grid', the step size for notch filling can be 
increased from 1 to 10 udrs, decreasing runtime by lOx. 

- add notch filling before fracturing to catch any notchs created at 
chunk boundaries. I have not noticed any of these, so for mnemo and 
euterpe, I believe this will run in the time it takes to do the notch 
check, which is only a fwe hours. 

We are very close to finished up both chips and if we could remove the notch false errors 
from the metals drc, I'd be very happy. 


Thanks , 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 
94089 

vanthof@microunity.com 1 408 734-810 0 
"Don't blame me! I didn't vote for him" 
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Cc: 

Subject: 


From: 
Sent: 
To: 


wampler (Kurt Wampler) 
Monday, March 27, 1995 8:53 PM 

'age'; 'billz'; 'brianl'; 'dickson'; 'geert'; 'hopper'; 'mws'; 'ong'; 'tbr'; 'torn'; Vo"; 'wampler'; 'wingard'; 
'woody' 

'solo'; Vanthof 
Target edits 


Hi, 


I've edited the following 16 hand- generated leaf cells to move Ml targets which were 
falling under our M2 "comb" obstructions used to limit M2 length generated by the maze & 
rip-up routers during final routing. All 16 cells passed LVS after the changes were made. 

ealnf 36s9x4a. ly 
scsof 1 . ly 
serbif lop . ly 
xcdecsw. ly 
xcecl2cmos . ly 
xcinvc . ly 
xclatbc . ly 
xcmux2 . ly 
xcmux3 . ly 
xcnand2c.ly 
xcnand3c . ly 
xcnand4 c . ly 
xcnrlatbc . ly 
xcvf f sw. ly 
xevrrsw. ly 
xeweake . ly 

The cells have been checked in, locked down, and releasebom ' ed. I will submit an update- 
chip to re-make /u/chip's version of the GARDS PDL files for these cells. 

For the snapshot version, we'll need a getbom in proteus/ compass/layouts, and a make in 
proteus/gards . I'll assume tbr will take care of the snapshot updates. (Tim, you might 
want to check with Dave to make sure that picking up these changes doesn't invalidate 
currently- running LVS jobs -- if any of these cells are used in the "small" euterpe design 
currently undergoing LVS, the new layouts might cause shorts or opens with the original 
GARDS routing. ) 

If I've broken anything, please page me and I'll try to put things aright. 


- Kurt 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Monday, March 27, 1995 11:54 PM 
'Kurt Wampler' 

'age (Alan Corry)'; 'billz (Bill Zuravleff)'; 'brianl (Brian Lee)'; 'dickson (Richard Dickson)'; 'geert 
(Geert Rosseel)'; 'hopper {Mark Hofmann)'; 'mws (Mark Semmelmeyer)'; 'ong (Warren R. 
Ong)'; 'tbr (Tim B. Robinson)'; 'torn (Tom Laidig)'; 'vo (Tom Vo)'; 'wampler (Kurt Wampler)'; 
'wingard (Drew Wingard)'; 'woody (Jay Tomlinson)'; 'solo (John Campbell)' 
Re: Target edits 


Kurt Wampler writes : 


>For the snapshot version, we'll need a getbom in 

>proteus /compass/ layouts, and a make in proteus/gards . I'll assume tbr 
>will take care of the snapshot updates. (Tim, you might want to check 
>with Dave to make sure that picking up these changes doesn't invalidate 
>currently- running LVS jobs -- if any of these cells are used in the 
>" small" euterpe design currently undergoing LVS, the new layouts might 
>cause shorts or opens 
with 

>the original GARDS routing.) 
> 

>If I've broken anything, please page me and I'll try to put things 
aright . 


I have no current euterpe lvs/drc stuff running, only mnerao and the checks are beyond the 
point of interacting with the new cells in /u/chip. 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 
94089 

vanthof@microunity.com 1 408 734-8100 
"Don't blame me! I didn't vote for him" 


> 


> - Kurt 


thanks , 
Dave 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Monday, March 27, 1995 11:56 PM 

Tom Eich' 

'abbott'; 'craig (Craig Hansen)'; 'graham'; *h' 
Re: Latest TCI spec 


Tom Eich wrote (on Mon Mar 27) : 

I can not imagine demo 1 ing the unit to customers and not getting a lot of 
questions about noise, reliability, and how we plan to cost-reduce. I 
doubt that the small size will mitigate these concerns. Pandora seems to 
me a better demonstrator anyway, in that is is configurable and expandable. 
The current Hestia product design, when it eventually functions, will 
really be more of a functional appearance model, and at the projected power 
levels, not suitable for any deployment, even trials (I keep hearing the 
word trials with respect to the current design) . I'm repeating myself 
here, but it seems to be necessary. 

I think we have to consider the current point of comparison, at least in the minds of some 
of the people who have seen Hestia at board meetings, is the current Orlando trial, where 
I gather it was even necessary to design and deploy special furniture to accomodate the 
many components necessary to get demo functionality. Bear in mind among this was an SGI 
workstation, certainly something containing a fan. If we feel in bad shape with the 
degree of work we will need to do to get to a low cost fanless design, we're a lot further 
along than that system. 

I think the reality is that real deployment of this kind of technology (from anyone) is a 
lot further out than the optimistic predictions of a year ago suggested. Mouss has made 
it clear that in the short term he's looking for opportunities which can make use of our 
existing chipset, either at the nominal power levels for products where fan cooling is 
acceptable, or at lower power levels where reduced performance is acceptable. Accordingly 
we have had most of our effort focussed on the final stages of completing these 
implementations. I for one feel it's vitally important we finish what we have and get 
real hardware into the hands of our applications developers as soon as possible. A 
serious power reduction redisign will be a major undertaking and while we have done enough 
to believe there is scope to find order a factor of 2 (and I realize this may not be 
enough) , it would have been a mistake to have taken a reset and increased risk to attempt 
this before we have got out of the starting block. 

To get more than the factor of 2, will I think involve rethinking the whole system not 
just employing circuit tricks. Curtis has already alluded to the possibility of employing 
more dedicated hardware (but which would still be integrated) to reduce the processing 
burden in Euterpe. This possibility should be on the table, as should a possible 
repartitioning of the analog and digital functions in Calliope once we have hard data on 
the performance of the analog and RF funtions in our process. We should combine this 
analysis with a serious analysis of cost reduction options, since clearly the two are very 
closely intertwined. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, March 28, 1995 12:23 AM 

'hopper (Mark Hofmann)' 

'bpw (B. P. Wong)'; 'geert (Geert Rosseel)'; Vant'; 'wampler (Kurt Wampler)' 
phi a/b flipped identified on Euterpe 


Mark Hofmann wrote (on Mon Mar 27) : 


Kurt and I had another look at the phi a/b flip this afternoon in the 
gtlta area . The problem turns out to be in the hookup of the gtlb to the 
phi a/b clock spars inside the cell crclkintll . ly- which is only used by 
the gtlb. 

Kurt has just completed the edits to this cell. It has been locked down 
and released. Tim, could you do a getbom in the Euterpe snapshot area? 
Then Dave can launch another LVS and, if we're lucky and we haven't 
introduced a metal 4 short, we'll be able to re- verify without a new 
Gards re-route. 

I assume what we need here is an update to the euterpe/proteus snapshot to get this 
layout, rather than the euterpe area itself. 
I'll fire it up now. 

If this is clean, then when Kurt's patches to the XC cells are checked 
in we'll soon be in good shape to run a full chip Euterpe LVS (after we 
get a completed route that is) . 

What's the eta on release of these edits? It may be expedient to pick these up in the 
same build. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Eich [tbe@microunity.com] 
Tuesday, March 28, 1995 12:35 AM 
'tbr (Tim B. Robinson)' 
'abbott'; 'craig'; 'graham'; 'h' 
Re: Latest TCI spec 


Tim wrote: 

>snip< 
> 

>I think we have to consider the current point of comparison, at least 
>in the minds of some of the people who have seen Hestia at board 
>meetings, is the current Orlando trial, where I gather it was even 
>necessary to design and deploy special furniture to accomodate the many 
>components necessary to get demo functionality. Bear in mind among 
>this was an SGI workstation, certainly something containing a fan. If 
>we feel in had shape with the degree of work we will need to do to get 
>to a low cost fanless design, we're a lot further along than that 
>system. 


That may not be the case for the product design. From my perspective, the issue boils 
down to dealing with a concentrated heat load vs. a distributed and lower heat load. Even 
the Indys that are the basis for the Orlando trial unit are -100W, with the MIPS processor 
an order of magnitude lower than our current power dissipation. Assuming that the 
competitors keep using low power&density twisty little processors, they have a mechanical 
product design and probably a total cost advantage. Not to deny that we may have other 
unique advantages, but we must be clear on this disadvantage and its cost. 

>snip< I 
>for one feel it's vitally important we finish what we have and get real 
>hardware into the hands of our applications developers as soon as 
>possible. A serious power reduction redisign will be a major 
undertaking and while we have done enough to believe there is scope to 
>f ind order a factor of 2 (and I realize this may not be enough) , it 
>would have been a mistake to have taken a reset and increased risk to 
>attempt this before we have got out of the starting block. 


Agreed, but don't we need to have a better defined plan for getting to the high volume 
solution that these applications would run on? Also, I still have doubts about whether we 
shouldn't have taken a reset on the thermal design, given where we are today. We could 
still reset, but only if the return is there to justify it. That is one issue we need to 
resolve when we consider producing any more Hestias beyond what we've purchased parts for 
at this time. Another is how much effort to put into stretching the RO's specs to meet 
the increased requirements. 

>To get more than the factor of 2, will I think involve rethinking the 
>whole system not just employing circuit tricks. Curtis has already 
>alluded to the possibility of employing more dedicated hardware (but 
>which would still be integrated) to reduce the processing burden in 
>Euterpe. This possibility should be on the table, as should a possible 
>repartitioning of the analog and digital functions in Calliope once we 
>have hard data on the performance of the analog and RF funtions in our 
>process. We should combine this analysis with a serious analysis of 
>cost reduction options, since clearly the two are very closely 
> intertwined . 


Typically, along as some flexibility is maintained, the earlier these analyses and trade- 
offs are made, the lower the cost of development and the shorter the time to market. Do 
you think that with Euterpe design almost completed we are close to the right time to 
begin work on this, or must we wait until Calliope and/or Euterpe are brought up to begin 


> 


>Tira 
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such tasks? 
One 

example of an issue that hinges on the answer to this question is whether simply using lab 
supplies with Hestia may save some misplaced effort, if the final product uses a 
synchronous rectifier instead of a switcher. 

-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
2 55 Caspian Dr. Sunnyvale, CA 94 089 
(408)734-8100, (408)734-813 6 fax 


tbe@microunity . com 
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From: tbr 

Sent: Tuesday, March 28, 1995 12:42 AM 

To: 'wampler (Kurt Wampler)' 

Cc: 'age'; 'billz'; 'brianl*; 'dickson'; 'geert'; 'hopper'; 'mws'; 'ong'; 'solo'; 'torn'; 'vanthof ; Vo'; 

'wampler 1 ; 'wingard'; 'woody' 

Subject: Target edits 

Follow Up Flag: Follow up 

Flag Status: Red 


Kurt Wampler wrote (on Mon Mar 27): 
Hi, 

I've edited the following 16 hand-generated leaf cells to move Ml targets 
which were falling under our M2 "comb" obstructions used to limit M2 length 
generated by the maze & rip-up routers during final routing. All 16 cells 
passed LVS after the changes were made. 

ealnf36s9x4a.ly 

scsof 1 .ly 

serbiflop.ly 

xcdecsw.ly 

xcecl2cmos.ly 

xcinvc.ly 

xclatbc.ly 

xcmux2.1y 

xcmux3.1y 

xcnand2c.ly 

xcnand3c.ly 

xcnand4c.ly 

xcnrlatbc.ly 

xcvffsw.ly 

xcvrrsw.ly 

xcweakc.ly 

The cells have been checked in, locked down, and releasebom'ed. I will 
submit an update-chip to re-make /u/chip's version of the GARDS PDL files 
for these cells. 

For the snapshot version, we'll need a getbom in proteus/compass/layouts, 
and a make in proteus/gards. I'll assume tbr will take care of the 
snapshot updates. (Tim, you might want to check with Dave to make sure 
that picking up these changes doesn't invalidate currently-running LVS 
jobs — if any of these cells are used in the "small" euterpe design 
currently undergoing LVS, the new layouts might cause shorts or opens with 
the original GARDS routing.) 

Good point, but too late! The getbom has been running for some time 
now and has picked up these layouts. I was under the impression that 
we needed the update asap to correct another layout edit to correct 
the massive clock hook up mismatch. 

If I've broken anything, please page me and I'll try to put things aright. 
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Will do! 
Tim 
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Subject: 


From: 
Sent: 
To: 
Cc: 


tbr (Tim B. Robinson) 

Tuesday, March 28, 1995 12:42 AM 

'wampler (Kurt Wampler)' 

'age'; 'billz'; 'brianl'; 'dickson'; 'geeif; 'hopper'; 'mws'; 'ong'; 'solo'; 'torn'; Vanthof; Vo'; 
'wampler'; 'wingard'; 'woody' 
Target edits 


Kurt Wampler wrote 


(on Mon Mar 27) : 


Hi, 


I've edited the following 16 hand- generated leaf cells to move Ml targets 
which were falling under our M2 "comb" obstructions used to limit M2 length 
generated by the maze & rip-up routers during final routing. All 16 cells 
passed LVS after the changes were made. 

ealnf 36s9x4a. ly 
scsof 1 . ly 
serbif lop . ly 
xcdecsw. ly 
xcecl2cmos . ly 
xcinvc . ly 
xclatbc . ly 
xcmux2 . ly 
xcmux3 . ly 
xcnand2c.ly 
xcnand3c . ly 
xcnand4c . ly 
xcnrlatbc . ly 
xcvf f sw. ly 
xevrrsw. ly 
xeweake . ly 

The cells have been checked in, locked down, and releasebom 1 ed . I will 

submit an update-chip to re-make /u/chip's version of the GARDS PDL files 
for these cells . 

For the snapshot version, we'll need a getbom in proteus/ compass/ layouts , 
and a make in proteus/gards . I'll assume tbr will take care of the 
snapshot updates. (Tim, you might want to check with Dave to make sure 
that picking up these changes doesn't invalidate currently- running LVS 
jobs if any of these cells are used in the "small" euterpe design 
currently undergoing LVS, the new layouts might cause shorts or opens with 
the original GARDS routing.) 

Good point, but too latei The getbom has been running for some time now and has picked up 
these layouts. I was under the impression that we needed the update asap to correct 
another layout edit to correct the massive clock hook up mismatch. 

If I've broken anything, please page me and I'll try to put things aright. 


Will do I 


Tim 


Exhibit C12 


Page 531 of 643 


Subject: 


Sent 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, March 28, 1995 12:47 AM 

'vanthof {vant)' 

'age (Alan Corry)'; 'billz (Bill Zuravleff)'; 'brianl (Brian Lee)'; 'dickson (Richard Dickson)'; 'geert 
(Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'mws (Mark Semmelmeyer)'; 'ong (Warren R. 
Ong)'; 'solo (John Campbell)'; 'torn (Tom Laidig)'; 'vo (Tom Vo)'; 'wampler (Kurt Wampler)'; 
'Kurt Wampler'; 'wingard (Drew Wingard)'; 'woody (Jay Tomlinson)' 
Re: Target edits 


vant wrote (on Mon Mar 27) : 

I have no current euterpe lvs/drc stuff running, only mnemo and the 
checks are beyond the point of interacting with the new cells in /u/chip. 

OK. I'll start the make as soon as the getbom completes. Hopefully it will be fast 
running. I'm not sure what needs to be remade in the euterpe area after the proteus 
update is done to pick up the clock fix. I think Tom will need to handle that. 
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From: 


tbr 


Subject: 


Sent: 


To: 


Cc: 


Tuesday, March 28, 1995 1:15 AM 
Tom Eich' 

'abbott'; 'craig'; 'graham'; 'h' 
Re: Latest TCI spec 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Eich wrote (on Mon Mar 27): 

Agreed, but don't we need to have a better defined plan for getting to the 
high volume solution that these applications would run on? Also, I still 
have doubts about whether we shouldn't have taken a reset on the thermal 
design, given where we are today. We could still reset, but only if the 
return is there to justify it. That is one issue we need to resolve when 
we consider producing any more Hestias beyond what we've purchased parts 
for at this time. Another is how much effort to put into stretching the 
RO's specs to meet the increased requirements. 

Agreed, but my reading of the current situation is that from Mouss's 
perspective, it's much more important we find a second channel for our 
technology (at current performance/power) than getting further into 
a single customer situation which is itself clouded with regulatory 
imponderables at this time. I think it's partly for this reason that mouss 
has backed off the urgency of the major redesign we clearly need. 

As regards the RO, I was under the impression from noel, that we have 
mainly been investing time, not cash $ in the RO improvements, since 
the arrangement with RO allows them to sell the module as a generic 
design to anyone, not just MU. This could be wrong information. 
If so, we should certainly be reconsidering if we should spend any 
more there. 

>To get more than the factor of 2, will I think involve rethinking the 
>whole system not just employing circuit tricks. Curtis has already 
>alluded to the possibility of employing more dedicated hardware (but 
>which would still be integrated) to reduce the processing burden in 
>Euterpe. This possibility should be on the table, as should a 
>possible repartitioning of the analog and digital functions in 
>Calliope once we have hard data on the performance of the analog and 
>RF fruitions in our process. We should combine this analysis with 
>a serious analysis of cost reduction options, since clearly the two 
>are very closely intertwined. 


Typically, along as some flexibility is maintained, the earlier these 
analyses and trade-offs are made, the lower the cost of development and the 
shorter the time to market. Do you think that with Euterpe design almost 
completed we are close to the right time to begin work on this, or must we 
wait until Calliope and/or Euterpe are brought up to begin such tasks? One 
example of an issue that hinges on the answer to this question is whether 
simply using lab supplies with Hestia may save some misplaced effort, if 


> 


>Tim 
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the final product uses a synchronous rectifier instead of a switcher. 

We are close, and in fact I owe curtis some discussions on exactly 
this wrt Euterpe. However, I think for Calliope we have to have some 
real characterisation data on the process before we can determine if 
other analog/digital partitioning might make sense. 

As far as synchronous recifiaction goes, would we expect this to 
materially affect the switching noise? As I understand it, this 
techique is really just a way of simulating rectifier diodes with 
essentially zero forward bias voltage. Doesn't the same basic 
switching still take place? 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, March 28, 1995 1:16 AM 

Tom Eich' 

'abbott'; 'craig'; 'graham'; 'h' 
Re: Latest TCI spec 


Tom Eich wrote (on Mon Mar 27) : 

Agreed, but don't we need to have a better defined plan for getting to the 
high volume solution that these applications would run on? Also, I still 
have doubts about whether we shouldn't have taken a reset on the thermal 
design, given where we are today. We could still reset, but only if the 
return is there to justify it. That is one issue we need to resolve when 
we consider producing any more Hestias beyond what we've purchased parts 
for at this time . Another is how much effort to put into stretching the 
RO's specs to meet the increased requirements. 

Agreed, but my reading of the current situation is that from Mouss ' s perspective, it's 
much more important we find a second channel for our technology (at current 
performance/power) than getting further into a single customer situation which is itself 
clouded with regulatory imponderables at this time. I think it's partly for this reason 
that mouss has backed off the urgency of the major redesign we clearly need. 

As regards the RO, I was under the impression from noel, that we have mainly been 
investing time, not cash $ in the RO improvements, since the arrangement with RO allows 
them to sell the module as a generic design to anyone, not just MU. This could be wrong 
information. 

If so, we should certainly be reconsidering if we should spend any more there. 

>To get more than the factor of 2, will I think involve rethinking the 
>whole system not just employing circuit tricks. Curtis has already 
>alluded to the possibility of employing more dedicated hardware (but 
>which would still be integrated) to reduce the processing burden in 
>Euterpe. This possibility should be on the table, as should a 
>possible repartitioning of the analog and digital functions in 
>Calliope once we have hard data on the performance of the analog and 
>RF funtions in our process. We should combine this analysis with 
>a serious analysis of cost reduction options, since clearly the two 
>are very closely intertwined. 


Typically, along as some flexibility is maintained, the earlier these 
analyses and trade-offs are made, the lower the cost of development and the 
shorter the time to market. Do you think that with Euterpe design almost 
completed we are close to the right time to begin work on this, or must we 
wait until Calliope and/or Euterpe are brought up to begin such tasks? 

One 

example of an issue that hinges on the answer to this question is whether 
simply using lab supplies with Hestia may save some misplaced effort, if 
the final product uses a synchronous rectifier instead of a switcher. 

We are close, and in fact I owe curtis some discussions on exactly this wrt Euterpe. 
However, I think for Calliope we have to have some real characterisation data on the 
process before we can determine if other analog/digital partitioning might make sense. 

As far as synchronous recifiaction goes, would we expect this to materially affect the 
switching noise? As I understand it, this techique is really just a way of simulating 
rectifier diodes with essentially zero forward bias voltage. Doesn't the same basic 
switching still take place? 


>Tim 


Tim 
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To: 


Subject: 


Sent: 


From: 


tbr 

Tuesday, March 28, 1995 1:33 AM 

Tom Eich 1 

Re: Latest TCI spec 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Eich wrote (on Mon Mar 27): 

Tim, one thing I wanted to mention that I've not discussed with you is that 
the lack of planning and product management wrt Hestia and its implications 
for ultimate success are not lost on the product-oriented engineers (hw or 
sw). To paraphrase an engineer (since departed) who has been exposed to 
the quite large and now solo SGI set-top effort, "they have better odds of 
having deployable hardware in I 1/2 years than microunity, based on 
technical risk and total product design capability". This problem cannot 
be blamed on poor internal communications at MicroUnity, as some would have 
it. 

I have to admit that I am probably as guilty as mouss in not taking 
into consideration the true scale of the work involved in getting 
something such as Hestia to real high volume. Mouss tends to 
oversimplify and consider the box as "just a package", which certainly 
does not do justice to the quality of the work you have done. 
My system level experience has all been with relatively modest volumes 
where it has been possible to wing it all too often. 

One of the reasons I'm pushing (and I don't mean to push you, as you're 
understandably too busy and it's not your responsibility anyway -- Jack and 
ultimately Mouss is my target here) for a more fully realized plan of 
attack is for the sake of the product oriented engineers like you and me. 

I feel I have not done as much as I should have, but I'm much happier 
dealing with the technical issues, and not good at the kind of 
wheeling and dealing that seems to be an essential part of getting a 
revolutionary product like this into a brand new market. As a 
result I have had almost no involvement in such discussions as there 
have been with the potential customers. 

Until that goal is realized, I personally can't muster the motivation to 
spend the excessive effort that I did during the last 6 months of '94 on 
Hestia. Also, I know my limitations, being an ME, and can't honestly 
assume responsibility for this management requirement. So I guess there is 
a selfish motive at work here also, but I believe it coincides with several 
practical reasons for better planning and product management. 

I understand. 

Btw, any word on the Steve Manser offer status? 

As far as I know an offer has been extended. I have no idea about how 
it was received. 

ps: Craig really dismayed me with his lawyerly but illogical response on 
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the TCI fan ban issue. I thought he was historically un enthusiastic about 
the set-top box as an application for our technology(?) I suspect he's 
upset with me, as he brushed past me in the hall this afternoon, but I 
can't abide such nonsense. 

Craig has always I think wanted to build mainstream "computer" type 
systems. I know he was one of the main opponents to cutting the FP 
functionality which was so necessary in my mind to have any shot at 
the set top application with Euterpe. However, that said, in some 
presentations I've participated in he has done a good job of 
rationalizing most of the decisions we did take. He has never been a 
believer in the ECL circuit technology we have been using. 

I think in all this we should not lose sight of the fact that even if 
we had the perfoect product (per the TCI spec), it's far from clear if 
there is a real prospect of them being bought in volume in the near 
future. As I understand it, the big interest in the cable modem and 
the InterNet access services is happening for two reasons. First it's 
just not clear if the FCC will allow enough freedom for the cable 
companies to be able to raise the capital needed to deploy the 
technology. Second, it's not clear that the kinds of services 
previously envisions (eg near video on demand) will ever result in 
enough revenue to justify the enormous investment. In contrast at 
present the InterNet is completely unregulated, and growing at a CAGR 
that no-one can ignore (eg WWW activity increasing at > 25%/month 
(yes, per month!). 

Tim 


Exhibit C12 


Page 537 of 643 


From: 


tbr 


Sent: Tuesday, March 28, 1 995 1 1 :46 AM 

To: 'vanthof (vant)' 

Cc: 'age (Alan Corry)'; 'billz (Bill Zuravleff)'; 'brianl (Brian Lee)'; 'Richard Dickson'; 'Geert 

Rosseel'; 'Mark Hofmann'; 'Mark Semmelmeyer'; 'Warren R. Ong'; 'John Campbell'; Tom 
Laidig'; 'Tom Vo'; 'Kurt Wampler'; 'Kurt Wampler'; 'Drew Wingard'; 'Jay Tomlinson' 

Subject: Re: Target edits 

Follow Up Flag: Follow up 

Flag Status: Red 


vant wrote (on Mon Mar 27): 

Kurt Wampler writes: 

> 
> 

>For the snapshot version, we'll need a getbom in proteus/compass/layouts, 
>and a make in proteus/gards. I'll assume tbr will take care of the 
>snapshot updates. (Tim, you might want to check with Dave to make sure 
>that picking up these changes doesn't invalidate currently -running LVS 
>jobs — if any of these cells are used in the "small" euterpe design 
>currently undergoing LVS, the new layouts might cause shorts or opens with 
>the original GARDS routing.) 
> 

>If I've broken anything, please page me and I'll try to put things aright. 

> 

>-Kurt 

> 

1 have no current euterpe lvs/drc stuff running, only mnemo and the 
checks are beyond the point of interacting with the new cells in /u/chip. 

The snapshot update completed. 

Tim 
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Sent: 
To: 

Cc: 


Subject: 


From: 


tbr (Tim B. Robinson) 

Tuesday, March 28, 1995 11:46 AM 

Vanthof (vant)' 

'age (Alan Corry)'; 'billz (Bill Zuravleff)'; 'brianl (Brian Lee)'; 'dickson (Richard Dickson)'; 'geert 
(Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'mws (Mark Semmelmeyer)'; 'ong (Warren R. 
Ong)'; 'solo (John Campbell)'; 'torn (Tom Laidig)'; Vo (Tom Vo)'; 'wampler (Kurt Wampler)'; 
'Kurt Wampler'; 'wingard (Drew Wingard)'; 'woody (Jay Tomlinson)' 
Re: Target edits 


vant wrote (on Mon Mar 27) : 
Kurt Wampler writes: 


>For the snapshot version/ we'll need a getbom in proteus/compass/layouts , 
>and a make in proteus/gards . I'll assume tbr will take care of the 
>snapshot updates. (Tim, you might want to check with Dave to make sure 
>that picking up these changes doesn't invalidate currently- running LVS 
>jobs --if any of these cells are used in the "small" euterpe design 
>currently undergoing LVS, the new layouts might cause shorts or opens with 
>the original GARDS routing . ) 
> 

>If I've broken anything, please page me and I'll try to put things aright. 


I have no current euterpe lvs/drc stuff running, only mnemo and the 
checks are beyond the point of interacting with the new cells in /u/chip. 

The snapshot update completed. 


> 


>- Kurt 


> 


Tim 
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From: 


tbr 


To: 


Sent: 


Subject: 


Tuesday, March 28, 1995 12:15 PM 
'tbe (Tom Eich)' 
Re: Latest TCI spec 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Eich wrote (on Tue Mar 28): 

Thanks for your reply. I hope Jack can wade through this thread and still 
be willing to pick up the product definition mantle. 

Thing about cable modems that worries me is that historically modems have 
always quickly become commodities with each successive technology step 
(V34 is now <$80!). The market seems like it would be even less tolerant 
of the competitive disadvantage of our approach than the set-top, but as 
you point out, it is growing like a weed, and 64QAM is a more rarified 
level than what's come before. If it does become commoditized, we won't 
likely find much profit there. 

I absolutely share these concerns, and I think I am actually in 
mouss's bad books right now for vociferously stating that position at 
a recent meeting! 

The other complaint I've heard from mainly sw types is with respect 

to adopting our current architecture to cable modems by spreading 

the QAM sw over the 5 threads, with each thread perhaps at 40-some MHz. 

Probably do-able (per Larry Yamano), but extremely suboptimal. If this 

product really gathers steam, can the architecture be modified to tailor 

it to the specific requirements? 

I think we'd have to and I think the action is with us hardware folks 
and tony right now to figure out what the right combination of 
microarchitecture and technology is for various possible product 
points. Ther is a lot of flexibility at the micro-architecture level 
with very little impact at the architectural level. For exmple, I 
know tony thinks there would be real potential in a single threaded 
100MHz design for embedded applications. We need to get the current 
Euterpe off our backs so we can put serious thought into this! 


Tim 
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From: vo (Tom Vo) 

Sent: Tuesday, March 28, 1995 12:47 PM 

To: 'Tim B. Robinson' 

Cc: 'vanthof (Dave Van't Hot)'; 'age (Alan Corry)'; 'billz (Bill Zuravleff)'; 'brianl (Brian Lee)'; 'dickson 

(Richard Dickson)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'mws (Mark 
Semmelmeyer)'; 'ong (Warren R. Ong)'; 'solo (John Campbell)'; 'torn (Tom Laidig)'; 'wampler 
(Kurt Wampler)'; 'wampler@microunity.com'; 'wingard (Drew Wingard)'; 'woody (Jay 
Tomlinson)' 

Subject: Re: Target edits 


Tim B. Robinson wrote 


>vant wrote (on Mon Mar 27) : 
> 

> I have no current euterpe lvs/drc stuff running, only mnemo and the 

> checks are beyond the point of interacting with the new cells in 
/u/chip. 

> 

>0K. I'll start the make as soon as the getbom completes. Hopefully it 
>will be fast running. I'm not sure what needs to be remade in the 
>euterpe area after the proteus update is done to pick up the clock fix. 
>I think Tom will need to handle that. 

I know of no clock fix in the euterpe area . The VDD/VSS short 

found several days ago by the mnemo SHORT test was due to 

operator 1 s error - - the build was not done in the correct sequence . 

tvo 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 
Tuesday, March 28, 1995 2:38 PM 
'geerf 

'brianl'; 'hopper'; 'tbr'; 'torn'; Vo'; 'wampler' 

Pin permutation of XBOR & XCNAND D-inputs 


Hi, 


Under the category "pulling out all the stops" we would like to incorporate the following 
extras into the general place/ route strategy: 

1) Add permutability properties to the D-inputs of all XBOR and XCNAND family 
gates. This can be done in topt or emerge by inserting the following code 
into the "emerge . tab" or "power. tab" files. 

# Add permutability attributes to XBOR. . . and XCNAND. . . D- input pins 
addport property xbor.* d.* EQ_CLASS PERMUTE 
addportproperty xcnand.* d.* EQ_CLASS PERMUTE 

Is /u/chip/proteus/misc/emerge . tab the right place to insert this code? 

2) Ask GPLACE to try harder with its component flipping optimization, and 
ask it to perform pin permutation at exit time. This would change our 
standard gplace.nic incantation to: ( " | " indicates changed lines ) 

readpif {design} .pif; ok 
makeauto use; ok 
iparam sweeps 0 ; 
| iparam iterations 5; 

iparam algorithm hper_net length; 
improve use; ok 

writenof {design} .nof ; use; ok 
| exit swaps ave 
exit no save 

Is it appropriate to make this change in both of these places? 
/u/chip/proteus/Makef ile . rules 
/u/chip/euterpe/verilog/bsrc/Makef ile. vo 


- Kurt 
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Sent: 
To: 

Cc: 


Subject: 


From: 


tbr (Tim B. Robinson) 

Tuesday, March 28, 1995 2:41 PM 

Vo (Tom Vo)' 

'age (Alan Corny)'; 'billz (Bill Zuravleff)'; 'brianl (Brian Lee)'; 'dickson (Richard Dickson)'; 'geert 
(Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'mws (Mark Semmelmeyer)'; 'ong (Warren R. 
Ong)'; 'solo (John Campbell)'; 'torn (Tom Laidig)'; Vanthof (Dave Van't Hof)'; 'wampler (Kurt 
Wampler)'; 'wampler@microunity.com'; 'wingard (Drew Wingard) 1 ; 'woody (Jay Tomlinson)' 
Re: Target edits 


Tom Vo wrote (on Tue Mar 28) : 
Tim B. Robinson wrote 


>vant wrote (on Mon Mar 27) : 
> 

> I have no current euterpe lvs/drc stuff running, only mnerao and the 

> checks are beyond the point of interacting with the new cells in 
/u/chip. 

> 

>0K. I'll start the make as soon as the getbom completes. Hopefully 
>it will be fast running. I'm not sure what needs to be remade in the 
>euterpe area after the proteus update is done to pick up the clock 
>fix. I think Tom will need to handle that. 

I know of no clock fix in the euterpe area . The VDD/VSS short 

found several days ago by the mnemo SHORT test was due to 

operator 1 s error - - the build was not done in the correct sequence . 


I think that was fully understood. Some cell inthe gtlb was getting hooked to the SOFA 
clock backwards . 


Tim 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, March 28, 1995 2:51 PM 

To: Vo (Tom Vo)' 

Cc: 'tbr (Tim B. Robinson)' 

Subject: Re: Target edits 

Tim B. Robinson writes: 

I know of no clock fix in the euterpe area . The VDD/VSS short 
found several days ago by the mnemo SHORT test was due to 
operator's error ~ the build was not done in the correct sequence . 

I think that was fully understood. Some cell inthe gtlb was getting 
hooked to the SOFA clock backwards. 

Hi Tom, 

Oops. Sorry I left you off the mail on this one. Here's what we found: 

>From hopper Mon Mar 27 15:24:39 1995 
Subject: phi a/b flipped identified on Euterpe 
To: geert (Geert Rosseel) 
Date: Mon, 27 Mar 95 15:24:39 GMT 

Cc: bpw (B. P. Wong), wampler (Kurt Wampler), tbr (Tim B. Robinson), vant 
X-Mailer: ELM [version 2.3 PL11] 


Kurt and I had another look at the phi a/b flip this afternoon in the 
gtlb area. The problem turns out to be in the hookup of the gtlb to the 
phi a/b clock spars inside the cell crclkintl l.ly- which is only used by 
the gtlb. 

Kurt has just completed the edits to this cell. It has been locked down 
and released. Tim, could you do a getbom in the Euterpe snapshot area? 
Then Dave can launch another LVS and, if we're lucky and we haven't 
introduced a metal 4 short, we'll be able to re-verify without a new 
Gards re-route. 

If this is clean, then when Kurt's patches to the XC cells are checked 
in we'll soon be in good shape to run a full chip Euterpe LVS (after we 
get a completed route that is). 

-thanks, 
hopper 
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From: tbr 

Sent: Tuesday, March 28, 1 995 3: 1 3 PM 

To: 'wampler (Kurt Wampler)' 

Cc: 'brianl'; 'geert'; 'hopper'; 'torn'; 'vo'; 'wampler* 

Subject: Pin permutation of XBOR & XCNAND D-inputs 

Follow Up Flag: Follow up 

Flag Status: Completed 


Kurt Wampler wrote (on Tue Mar 28): 
Hi, 

Under the category "pulling out all the stops" we would like to incorporate 
the following extras into the general place/route strategy: 

1) Add permutabitity properties to the D-inputs of all XBOR and XCNAND family 
gates. This can be done in topt or emerge by inserting the following code 

into the "emerge.tab" or "power .tab" files. 

# Add permutability attributes to XBOR... and XCNAND... D-input pins 
addportproperty xbor. * d . * EQ_CLASS PERMUTE 
addportproperty xcnand.* d.* EQ_CLASS PERMUTE 

Is Ai/chip/proteus/misc/emerge.tab the right place to insert this code? 

As far as I am aware all the relevant rules int he standard flow 
ultimately derive their emerg.tab files from this one. So, I'd say 
yes this is the right place. 

2) Ask G PLACE to try harder with its component flipping optimization, and 
ask it to perform pin permutation at exit time. This would change our 
standard gplace.nic incantation to: ( "|" indicates changed lines ) 

readpif {design}. pif; ok 

makeauto use; ok 

iparam sweeps 0; 
j iparam iterations 5; 

iparam algorithm hper_netlength; 

improve use; ok 

writenof {design}. nof; use; ok 
| exitswapsave 

exitnosave 

Is it appropriate to make this change in both of these places? 
/u/chip/proteus/Makefile. rules 
/u/chip/euterpe/verilog/bsrc/Makefile.vo 

If we are going to make these changes as standard in proteus (and we probably 
should), then you should also check the mnemo Makefiles for additional 
places. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, March 28, 1995 3:13 PM 

'wampler (Kurt Wampler)* 

'brianl'; 'geert'; 'hopper'; 'torn'; Vo'; 'wampler' 

Pin permutation of XBOR & XCNAND D-inputs 


Kurt Wampler wrote (on Tue Mar 28) : 


Hi, 


Under the category "pulling out all the stops" we would like to incorporate 
the following extras into the general place/route strategy: 

1) Add permutability properties to the D-inputs of all XBOR and XCNAND family 
gates. This can be done in topt or emerge by inserting the following code 
into the "emerge . tab" or "power. tab" files. 


# Add permutability attributes to XBOR. . . and XCNAND. . . D- input pins 
addportproperty xbor.* d.* EQ_CLASS PERMUTE 
addportproperty xcnand.* d.* EQ_CLASS PERMUTE 

Is /u/chip/proteus/misc/emerge . tab the right place to insert this code? 

As far as I am aware all the relevant rules int he standard flow ultimately derive their 
emerg.tab files from this one. So, I'd say yes this is the right place. 

2) Ask G PLACE to try harder with its component flipping optimization, and 
ask it to perform pin permutation at exit time. This would change our 
standard gplace.nic incantation to: ( "J" indicates changed lines ) 

readpif {design} .pif ; ok 
makeauto use; ok 
iparam sweeps 0 ; 
| iparam iterations 5; 

iparam algorithm hper_net length; 
improve use; ok 

writenof {design} . nof ; use; ok 
| exit swap save 
exit no save 

Is it appropriate to make this change in both of these places? 
/u/chip/proteus/Makef ile . rules 
/u/chip/euterpe/verilog/bsrc/Makef ile . vo 

If we are going to make these changes as standard in proteus (and we probably should) , 
then you should also check the mnemo Makefiles for additional places. 


Tim 
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From: vanthof (vant) 

Sent: Tuesday, March 28, 1995 4:25 PM 

To: 'wampler (Kurt Wampler)' 

Cc: 'brianl (Brian Lee)'; 'hopper (Mark Hofmann)'; 'tbr (Tim B. Robinson)'; 'torn (Tom Laidig)'; 'vo 

(Tom Vo)'; 'geert (Geert Rosseel)'; Vanthof (Dave Van't Hof)' 
Subject: Pin permutation of XBOR & XCNAND D-inputs 


Hi, 

This was forwarded on to me and I hope I understand what is going to tried, and if I 
don't then, please ignore me. There is a nasty problem which will occur if permutability 
is implemented: 

LVS won 1 1 work . 

The first thing dracula does is flatten the netlist into discrete transistors and then use 
that to verify against the layout. If pins are permuted, the netlist no longer matches 
the layout . 

ISS does handle permutability, but ISS does not like the baseplate methodology and we have 
not built up the necessary hierarchy information for ISS on any of the chips. To use ISS 
requires changes to the existing hierarchy. 

We could »in theory' extract what has been permuted and feed that back into the netlist, 
however, we are now changing the original input netlist to match the layout and that could 
hide potential problems. The VII/VRR lines are currently done in this fashion, but those 
connection changes don't directly impact logical connectivity. 

We must really really really want to do this, and if we do, we must have an workable 
solution to the netlist munging. 

Thanks , 
Dave 

>Kurt Wampler writes: 

> Hi, 
> 

> Under the category "pulling out all the stops" we would like to 
incorporate 

> the following extras into the general place/route strategy: 
> 

> 1) Add permutability properties to the D-inputs of all XBOR and 

> XCNAND 
family 

> gates. This can be done in topt or emerge by inserting the 
following code 

> into the "emerge. tab" or "power. tab" files. 
> 

> # Add permutability attributes to XBOR. . . and XCNAND. . . D-input 
pins 

> addportproperty xbor.* d.* EQ_CLASS PERMUTE 

> addportproperty xcnand . * d . * EQ_CLASS PERMUTE 
> 

> Is /u/chip/proteus/misc/emerge. tab the right place to insert this 
code? 

> 

> 2) Ask G PLACE to try harder with its component flipping 

> optimization, 
and 

> ask it to perform pin permutation at exit time. This would 

> change 
our 

> standard gplace.nic incantation to: ( "|" indicates changed 

> lines 
) 
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> readpif {design} . pif ; ok 

> makeauto use; ok 

> iparam sweeps 0 ; 

> | iparam iterations 5; 

> iparam algorithm hper_net length; 

> improve use; ok 

> writenof {design} . nof ; use; ok 

> | exitswapsave 

> exitnosave 
> 

> Is it appropriate to make this change in both of these places? 

> /u/chip/proteus/Makef ile . rules 

> /u/chip/euterpe/verilog/bsrc/Makef ile . vo 
> 

> - Kurt 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 
94089 

vanthof@microunity.com 1 408 734-8100 
"Don't blame me I I didn't vote for him" 
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Sent: 
To: 

Cc: 


Subject: 


From: 


tbr 

Tuesday, March 28, 1995 4:28 PM 

'geert' 

'torn' 

obsolete repository 


Follow Up Flag: Follow up 
Flag Status: Completed 

ghidra:/s3/euterpe/verilog/bsrc 

had pointers to the obsolete repository name. I ran toms fix-rep 
script to update it for /p/cvsroot 


Tim 
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From: wampler (Kurt Warn pier) 

Sent: Tuesday, March 28, 1995 8:01 PM 

To: 'geert' 

Cc: 'brianl'; 'hopper'; 'tbr'; 'torn'; 'vo'; 'wampler' 

Subject: Re: Pin permutation of XBOR & XCNAND D-inputs 


For the 5PM disturbance, I've releasedbom' ed the following files to implement pin 
permutation on xbor & xcnand gates, and to increase the iteration count for component flip 
optimization to a maximum of 5 passes: 

proteus /mi sc /emerge . tab 
proteus/Makef ile . rules 
euterpe/verilog/bsrc/Makef ile . vo 
mnemo/verilog/src/Makef ile . vo 

If I made any fatal typo's or otherwise broke things please let me know & I'll attempt to 
correct . 
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From: 


tbr 


To: 


Subject: 


Sent: 


Cc: 


Wednesday, March 29, 1995 12:06 AM 

Tom Laidig (tau)' 

, tau@rhea' 

Re: pager log message 


Follow Up Flag: Follow up 
Flag Status: Red 

tau wrote (on Tue Mar 28): 

Tim B. Robinson writes: 

I 

| page from tbr to torn: 
jHelp! /u/chip 100% full, tbr 

Sorry, I was at a restaurant. I'm now moving /u/chip/hephaestus and 
/u/chip/orchis to /n/rama/slO to clear some space for the immediate 
term. 

Do you know what was building when the disk filled? I've been watching 
the free space on that disk for a while, and although it was low, there 
had been a pretty steady 35Meg free... obviously not a big enough margin. 

No. I have stuff running in the euterpe snapshot, but that should not 
be putting anything /u/chip. I discovered it really 100% full when I 
could not write out the .cshrc. interactive from the editor! I found 
an 8MB core file to remove, which let me write it out, but it filled 
up again pretty quickly. 


Tim 
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To: 


Subject: 


From: 
Sent: 


tbr 

Wednesday, March 29, 1995 1:18 AM 
'warn pier" 

another gplace funny 


Follow Up Flag: Follow up 
Flag Status: Red 

I just had this happen (nosferatu): 

GPLACE Version 7. 1 .26 of September 9, 1994 

No component hierarchy found; select by hierarchy disabled. 

Loading components... 

Loading nets... 

Loading logical types... 

Processing physical types... 

Loading celMypes... 

Creating net-comp xref table... 

Ran out of memory. gmake [2]: *** [gards/es-pass2. gplace. lis] Error 1 

gmake[2]: Leaving directory ^/N/auspex3/s41/euterpe-snapshot/euterpe/verilog/bsrc/es' 

gmakefl]: *** [es-base. short. nets] Error 1 

gmake[l]: Leaving directory , /N/auspex3/s41/euterpe-snapshot/euterpe/verilog/bsrc/es' 
gmake: *** [esgards] Error 1 

A C[1] + Exit 1 gmake esgards » & makerrs 

chip@nosferatu /N/auspex3/s41/euterpe-snapshot/euterpe/verilo^src/es 27 % pstat -s 
123988k allocated + 10600k reserved = 134588k used, 1570328k available 

Doesn't look like a swap space problem. I'll restart it and see if it 
repeats. 


Tim 
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From: wampler (Kurt Wampler) 

Sent: Wednesday, March 29, 1 995 1 :44 AM 

To: tor" 

Subject: Re: another g place funny 

>I just had this happen (nosferatu): 

> 

> G PLACE Version 7. 1.26 of September 9, 1 994 

> 
> 

>Ran out of memory .gmake [2]; *** [gards/es-pass2. gplace. lis] Error 1 

>chip@nosferatu /N/auspex3/s41/euterpe-snapshot/euterpe/veriIog/bsrc/es 27 % pstat -s 

> 123 98 8k allocated + 10600k reserved = 134588k used, 1570328k available 

> 

>Doesn't look like a swap space problem. I'll restart it and see if it 
>repeats. 

Looks like it got past gplace this time. Very strange. Surveying the 
gplace binary, I find dozens of "Ran out of memory" strings in it; 
apparently there are many ways it can run out of memory(!) Was the 
failure earlier today also on nosferatu? 1 suppose there could have 
been a transient process (or some big job that was just finishing up) 
that had most of memory & swapspace tied up, and then relinquished 
it just after gplace crashed. 

Anyway, I don't see any other obvious clues upon first examination. 
Perhaps rebooting nosferatu would be worth a try. 

-Kurt 
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From: hopper (Mark Hofmann) 

Sent: Wednesday, March 29, 1995 7:10 AM 

To: Vant' 

Cc: 'hopper@microunity.com'; 'ken@microunity.com'; 'torn (Tom Laidig)'; 'Kurt Wampler'; 'sysadm'; 
'Guillermo A. Loyola' 

Subject: Re: trex status 
vant writes: 

I'm sort of waiting for trex to become stable, as I have jobs which take 
multiple days. Is it possible to move that upgrade for trex to today so 
trex can be used? 

Ken, 

As Gmo suggests, perhaps we ought to hold orTon the 5.3 upgrade 
on Trex. So, let's apply the patches as you propose. 

Since this is a critical tapeout machine, can you coordinate with Dave on 
the scheduled downtime? 

-thanks, 
hopper 
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From: torn (Tom Laidig (tau)) 

Sent: Wednesday, March 29, 1995 8:58 AM 

To: Tom Laidig (tau)' 

Cc: 'tbr (Tim B. Robinson)'; Vanthof (Dave Van't Hot)' 
Subject: Re: pager log message 

Tom Laidig (tau) writes: 

! 

|Do you know what was building when the disk filled? I've been watching 
|the free space on that disk for a while, and although it was low, there 
jhad been a pretty steady 35Meg free... obviously not a big enough margin. 

I found it: 

-clio:tom-> ll /u/chip/euterpe/verilog/bsrc/nb/core 

32224 -rw-r-r- 1 chip cad 32980992 Mar 28 1 6:46 /u/chip/euterpe/verilog/bsrc/nb/core 
-clio:tom-> file /u/chip/euterpe/verilog/bsrc/nb/core 
/u/chip/euterpe/verilog/bsrc/nb/core: core file from 'topt' 

Dave, is there any useful info to be gleaned from the core file (which 
may be an incomplete file, for that matter), or should we just nuke it? 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Wednesday, March 29, 1995 9:42 AM 

'torn (Tom Laidig (tau)' 

Vanthof 

Re: pager log message 


Follow Up Flag: Follow up 
Flag Status: Red 

tau wrote (on Wed Mar 29): 

Tom Laidig (tau) writes: 
I 

|Do you know what was building when the disk filled? IVe been watching 
jthe free space on that disk for a while, and although it was low, there 
(had been a pretty steady 35Meg free... obviously not a big enough margin. 

I found it: 

-clio:tom-> 11 /u/chip/euterpe/verilog/bsrc/nb/core 

32224 -rw-r-r- 1 chip cad 32980992 Mar 28 16:46 /u/chip/euterpe/verilog/bsrc/nb/core 
-clio:tom-> file /u/chip/euterpe/verilog/bsrc/nb/core 
/u/chip/euterpe/verilog/bsrc/nb/core: core file from 'topf 

Dave, is there any useful info to be gleaned from the core file (which 
may be an incomplete file, for that matter), or should we just nuke it? 

Interesting, because overnight I have built nb in the snapshot area 
from this same BOM with no prroblem. 

BTW, there is something about the mail header (I think the doubly 
nested parens) which means that when I try to reply wit V in VM, the 
cc list gets dropped. I only ever seem to have this problem with mail 
from you, and then only sometimes! 


Tim 
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From: vanthof (vant) 

Sent: Wednesday, March 29, 1995 9:44 AM 
To: 'Tom Laidig (tail)' 

Cc: 'tom@microunity.com'; 'tbr (Tim B. Robinson)' 
Subject: Re: pager log message 

Tom Laidig (tau) writes: 

> 

>Tom Laidig (tau) writes: 

>l 

>|Do you know what was building when the disk filled? I've been watching 
>|the free space on that disk for a while, and although it was low, there 
>|had been a pretty steady 35Meg free... obviously not a big enough margin. 

> 

>I found it: 

> 

> -clio:tom-> 11 /u/chip/euterpe/verilog/bsrc/nb/core 

> 32224 -rw-r-r-- 1 chip cad 32980992 Mar 28 16:46 /u/chip/euterpe/verilog/bsrc/nb/core 

> -clio:tom-> file /u/chip/euterpe/verilog/bsrc/nb/core 

> /u/chip/euterpe/verilog/bsrc/nb/core: core file from 'topt' 

> 

>Dave, is there any useful info to be gleaned from the core file (which 
>may be an incomplete file, for that matter), or should we just nuke it? 

> 

Well, 1 tried to gdb the core file with the topt binary and it apparently 
died when trying to flatten the netlist. I've gotten enough information 
to run some tests and sure enough, it is getting a segv in the flatten 
routine of nb.edif. Something has changed somewhere in the edif netlist 
format and topt doesn't like it. 

So, sure go ahead and blow it away. 

Thanks, 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 
"Don't blame me! I didn't vote for him" 
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From: vanthof (vant) 

Sent: Wednesday, March 29, 1995 9:46 AM 
To: Tom Laidig (tail)' 

Cc: Vanthof (Dave Van't Hot)'; 'tbr (Tim B. Robinson)' 
Subject: Re: pager log message 

Tom Laidig (tau) writes: 

> 

>Tom Laidig (tau) writes: 

>\ 

>|Do you know what was building when the disk filled? I've been watching 
>|the free space on that disk for a while, and although it was low, there 
>|had been a pretty steady 35Meg free... obviously not a big enough margin. 

> 

>I found it: 

> 

> -cl io:tom-> 1 1 /u/chip/euterpe/veri log/bsrc/nb/core 

> 32224 -rw-r-r- 1 chip cad 32980992 Mar 28 16:46 /u/chip/euterpe/verilog/bsrc/nb/core 

> -clio:tom-> file /u/chip/euterpe/verilog/bsrc/nb/core 

> /u/chip/euterpe/verilog/bsrc/nb/core: core file from 'topt' 

> 

>Dave, is there any useful info to be gleaned from the core file (which 
>may be an incomplete file, for that matter), or should we just nuke it? 

> 

Sheesh, This day is starting out crazy for me already... The gdb died alright, 
but because of a silly mistake on my part. The flattening works, so I'm 
confused about this one... rerunning the job with enough space might fix it? 

Thanks 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 
"Don't blame me! I didn't vote for him" 
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From: billz (Bill Zuravleff) 

Sent: Wednesday, March 29, 1995 1 0:20 AM 

To: 'tbr' 

Subject: Re: dr 

I have BOM 67.0 (from top level 266.0), and it ran for 10 iterations 
without converging, and then gave up. Are you expecting it to 
converge? 

Well, let's see. *My* dr gards run converged in 7 iterations. 
However, I don't believe I've gotten it to converge in /u/chip 
using the .checkoutrc script recently. Metal 3 routing is very 
tight, and I've noticed great variations in the number of iterations 
to converge and the number of unrouted nets due to perhaps small 
cell changes (I alternately point my euterpe/proteus at /u/chip/proteus 
or the snapshot, at the moment /u/chip/proteus) or routing order 
of the nets. 

So, yes I expect it to converge; but, no, I'm not surprised it 
doesn't. Let me know how I can be of assistance. 
Regards, 
billz 
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From: 


tbr 


To: 


Subject: 


Sent: 


Wednesday, March 29, 1995 10:28 AM 
'billz (Bill Zuravleff)' 
Re: dr 


Follow Up Flag: Follow up 
Flag Status: Red 

Bill Zuravleff wrote (on Wed Mar 29): 

I have BOM 67.0 (from top level 266.0), and it ran for 10 iterations 
without converging, and then gave up. Are you expecting it to 
converge? 

Well, let's see. *My* dr gards run converged in 7 iterations. 
However, 1 don't believe I've gotten it to converge in /u/chip 
using the .checkoutrc script recently. Metal 3 routing is very 
tight, and I've noticed great variations in the number of iterations 
to converge and the number of unrouted nets due to perhaps small 
cell changes (I alternately point my euterpe/proteus at /u/chip/proteus 
or the snapshot, at the moment /u/chip/proteus) or routing order 
of the nets. 

So, yes I expect it to converge; but, no, I'm not surprised it 
doesn't. Let me know how I can be of assistance. 

Please look at the -iter results in the s41 snapshot area and see how 
it looks, and how many paths have failed to make it. As it was 
iterating 1 noticed is started out very ragged at the top and there 
has obviously been a lot of pifpacking going on which I would expect 
to slow down the convergence. 


Tim 
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Sent: 

To: 

Cc: 


From: 


woody (Jay Tomlinson) 

Wednesday, March 29, 1995 11:01 AM 

'sysadm' 

'torn' 


Subject: /u/chip space problem? 

Any idea what happened here? This was running on gamorra. 
woody 

Start of forwarded message 

<snip snip> 

/n/auspex/slO/chip/euterpe/tools/bin/planet: Maximum output plane fan in: 12 [opCmpltn] 
/n/auspex/slO/chip/euterpe/tools/bin/planet: 5 pirn rows produced 
gmake[2]: *** [gards/lt-passl. strength] Bus error (core dumped) 
gmake[2]: *** [gards/lt-passl. strength] Deleting file 'gards/It-pass l.topt.log' 
gmake[2]: *** [gards/lt-passl. strength] Deleting file 1 gards/lt-passl. stat' 
gmake[2]: *** [gards/lt-passl. strength] Deleting file 'gards/lt-passl.sdl' 
gmakefl]: *** [It-base. short. nets] Error 1 
gmake: *** [ltgards] Error 1 

<snip snip> 

End of forwarded message 
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From: torn (Tom Laidig [tauj) 

Sent: Wednesday, March 29, 1 995 1 1 :08 AM 

To: 'Jay Tomlinson' 

Cc: 'sysadm'; 'tau'; Vanthof (Dave Van't Hof)' 
Subject: Re: /u/chip space problem? 

Jay Tomlinson writes: 
I 

|Any idea what happened here? This was running on gamorra. 
jwoody 

j start of forwarded message 

|<snip snip> 
I 

|/n/auspex/slO/chip/euterpe/tools/bin/planet: Maximum output plane fan in: 12 [opCmpltn] 

j/n/auspex/slO/chip/euterpe/tools/bin/planet: 5 pirn rows produced 

|gmake[2]: *** [gards/lt-pass 1 .strength] Bus error (core dumped) 

|gmake[2]: *** [gards/lt-pass 1. strength] Deleting file 1 gards/lt-pass 1 .topt. log' 

|gmake[2]: *** [gards/lt-pass 1. strength] Deleting file ' gards/lt-pass l.stat' 

|gmake[2]: *** [gards/lt-pass 1. strength] Deleting file ' gards/lt-pass l.sdP 

|gmake[l]: *** [lt-base.short.nets] Error 1 

jgmake: *** [Itgards] Error 1 

I 

|<snip snip> 

j End of forwarded message 

I 

Well, I think this is pretty much what caused yesterday's space crunch, 
but your error wasn't caused by running out of disk space I think. 

-clio:tom-> 11 /u/chip/euterpe/verilog/bsrc/lt/core 

26064 -rw-r~r- 1 chip cad 34861488 Mar 29 07:55 /u/chip/euterpe/verilog/bsrc/lt/core 
-clio:tom-> file /u/chip/euterpe/verilog/bsrc/lt/core 
/u/chip/euterpe/verilog/bsrc/lt/core: core file from 'topt' 
-clio:tom-> 

There's still 28Meg left on that device (enough for one more core file, 
perhaps :-). 

Dave, do you want to delete the core file as soon as there's no useful 
info to be gleaned (which is maybe now)? 
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From: vanthof (vant) 

Sent: Wednesday, March 29, 1 995 1 1 : 1 9 AM 
To: Tom Laidig [tau]' 

Cc: 'woody@microunity.com'; 'sysadm'; 'vanthof (Dave Van't Hof)' 
Subject: Re: /u/chip space problem? 

Tom Laidig [tau] writes: 

> 

>Well, I think this is pretty much what caused yesterday's space crunch, 
>but your error wasn't caused by running out of disk space I think. 

> 

> -clio:tom-> U /u/chip/euterpe/verilog/bsrc/lt/core 

> 26064 -rw-r-r- 1 chip cad 34861488 Mar 29 07:55 /u/chip/euterpe/verilog/bsrc/lt/core 

> -clio:tom-> file /u/chip/euterpe/verilog/bsrc/lt/core 

> /u/chip/euterpe/verilog/bsrc/lt/core: core file from 'topt' 

> -clio:tom-> 

> 

>There's still 28Meg left on that device (enough for one more core file, 
>perhaps :-). 

> 

>Dave, do you want to delete the core file as soon as there's no useful 
>info to be gleaned (which is maybe now)? 

> 

This core file can be deleted. 

I'm very confused. We had several jobs die last night from 'bus errors' 
in topt. The binary hasn't changed, and when I run them this morning, 
I'm not seeing the errors. 

This will take some more debugging work... 

Thanks, 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity .com 1 408 734-8 1 00 
"Don't blame me! I didn't vote for him" 
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From: vanthof (vant) 

Sent: Wednesday, March 29, 1995 12:23 PM 
To: Tom Laidig [tau]' 

Cc: 'dickson (Richard Dickson)'; "woody (Jay Tomlinson)'; 'tbr (Tim B. Robinson)'; 'Kurt Wampler'; 'tau'; 
'Mark Hofmann' 

Subject: Re: releases in euterpe/verilog/bsrc... 

Tom Laidig [tau] writes: 

> 

>I strongly doubt that the releases of ctioi, ctiod, he, and es now in 
>the chipq will work. It seems that, since yesterday afternoon (since 
>the addition of some stuff in proteus/misc/emerge.tab to enable pin 
>permuating?), topt is reliably core-dumping in /u/chip. This is 
>unfortunate, since the second such core dump fills the disk to 100%. 
>I've been trying to keep up with deleting the core files, but that's 
>not very reliable. 
> 

>\ recommend killing the released jobs (chipq -k 4I4[6789]) before this 
>happens. 

> 

>And we gotta get this to stop core-dumping... 

> 

I'm actively working on it... 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 
"Don't blame me! I didn't vote for him" 
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From: Potatoe Chip [chip@rhea] 

Sent: Wednesday, March 29, 1995 12:25 PM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/es BOM 82,0 initiated by dickson completed @ Wed Mar 29 
09:25:22 PST 1995 with exit status 1.. chip 


Exhibit C12 


Page 565 of 6 


From: vo (Tom Vo) 

Sent: Wednesday, March 29, 1995 12:57 PM 
To: Tim B. Robinson' 
Cc: 'ken (Ken Hsieh)'; 'geert (Geert Rosseel)' 
Subject: Re: need more space on auspex 

Tim B. Robinson wrote .... 

> 
> 

>Tom, how much more would you like? 1 see 1 94MB there now, and about 
>1 10MB taken up by two packages (tma and tma.old) which should not be 
>sharing the same partition as users. Ken, can you check if one of 
>these is obsolete and move what's not to a packages only partition? 

> 

Yesterday , that disk got full a couple of times . I think whoever 
did it cleared enough to free 194MB . Usually there isn't much 
space availble . I must have gotten 100+ messages from ericm asking 
me to clean up even though I use only 80MB of space . 

According to age , who kept his sources on the auspex , and 
GARDS results on the scratch disk , 400MB is about the minimum 
he can tolerate for the 3 designs that he checked 
out (mnemo, calliope, mnemosyne) . 

If I extrapolate to the 4 designs I have (mnemo,calliope,euterpe,cronus) 
I would say at 600M is about the minimum for me . I don't keep as many 
verilog dump files around but I do have all the baseplate/layout stuffs 


tvo 
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From: biflz (Bill Zuravteff) 

Sent: Wednesday, March 29, 1 995 1 :25 PM 

To: 'tbr (Tim B. Robinson)'; 'geert (Geert Rosseel)' 

Subject: Re: dr doesn't converge 

Tim, 

Re: dr doesn't converge 

I can't account for the differences in my run versus the run in 
.../s41/euterpe-snapshot/... but for that run, there are several 
nets in the lowest quadrant which don't route because all of the 
veritical routing resources have been used up. A way to fix this 
might be to introduce a column of spacer cells which keep the real 
cells further apart and create more, local veritical routing 
resources. Do you suggest I try this? 

billz 
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From: 
Sent: 
To: 

Subject: 


dickson (Richard Dickson) 
Wednesday, March 29, 1995 3:03 PM 
'geert' 

rich_euterpe 


geert , 


i was just looking at my toplevel route and still see a couple of problems, i moved 
the sumation logic to the lower side of es whwere there was some extra space, it caused a 
couple of unroutes in that area. 

does my makefile target wire the longest nets first as in your jobs ??? 
also i noticed mc data path is not pitched matched exactly. 

for a while we were pif packing this one alot and gates have wandered out of the bit pitch. 


dickson 
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From: hopper (Mark Hofmann) 

Sent: Wednesday, March 29, 1995 5:01 PM 

To: Tim B. Robinson' 

Cc: 'lisar (Lisa Robinson)' 

Subject: Re: verilog?- last chance... 

Tim B. Robinson writes: 

Sorry, mark, kept meaning to respond on this one. We are going 
through a peak right now, which I think will drop off shortly once 
Euterpe is finally behind us. Is there a logfile anywhere that shows 
the usage? I know lisar has failed to get a license a few times, but 
usage is peaky. If we are near the limint much of the time during the 
day, we should do it, if we typically have a couple of spares and 
only hit the limit occasionally I'd hold off. $35K is a lot, and 
the downside is really only the delta discount. 


Okay. 

Here's what I come up with from the log file: 

3/24 17:16:01 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pelorus(pel agon: 0.0) 

3/24 17:3 1 :05 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@pelorus(pelagon:0.0) 

3/24 17:33:49 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@merope(pelagon:0.0) 

3/24 17:33:53 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@merope(pelagon:0.0) 

3/24 17:33:58 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@merope(pelagon:0,0) 

3/24 17:34:07 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@merope(pelagon:0.0) 

3/24 17:34:25 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@merope(pelagon:0.0) 

3/24 17:34:58 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@merope(pelagon:0.0) 

3/24 17:37:52 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@mercury(pelagon:0.0) 

3/24 17:37:55 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@mercury(pelagon:0.0) 

3/24 17:38:00 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@hera(pelagon:0.0) 

3/24 17:38:01 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@mercury(pelagon:0.0) 

3/24 17:38:01 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ares(pelagon:0.0) 

3/24 17:38:11 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@mercury(pelagon:0.0) 

3/24 17:38:18 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@merope(pelagon:0.0) 

3/24 17:38:28 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@mercury(pelagon:0.0) 

3/24 17:38:39 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@narcissus(pel agon: 0.0) 

3/24 17:39:01 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@mercury (pel agon: 0.0) 

3/24 17:39:05 (cdslmd) DENIED: VERILOG-XL v2.000 by veena@godzilla( 192.2 16. 192.204:0.0) 

3/24 17:42:07 (cdslmd) DENIED: VERILOG-XL v2.000 by deepak@nosferatu(hard034:0.0) 

3/24 17:42:18 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@mercury(pelagon:0.0) 

3/24 17:42:36 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@merope(pel agon: 0.0) 

3/24 17:43:47 (cdslmd) DENIED: VERILOG-XL v2.000 by deepak@nosferatu(hard034:0.0) 

3/24 17:45:08 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@polyhymnia(pelagon:0.0) 

3/24 17:45:1 1 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@polyhymnia(pelagon:0.0) 

3/24 17:45:16 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@polyhymnia(pelagon:0.0) 

3/24 17:45:26 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@polyhymnia(pelagon:0.0) 

3/24 17:45:43 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@polyhymnia(pelagon:0.0) 

3/24 17:46:1 1 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pelorus(pelagon:0.0) 

3/24 1 7:49:20 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@frodo(peI agon: 0.0) 

3/24 17:49:24 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@frodo(pelagon:0.0) 

3/24 17:49:30 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@frodo(pel agon: 0.0) 

3/24 17:49:33 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@polyhymnia(pelagon:0.0) 

3/24 17:49:40 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@frodo(pelagon:0.0) 

3/24 17:49:57 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@frodo(pelagon:0.0) 

3/24 17:53:01 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@hera(pelagon:0.0) 
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3/24 17:53:03 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ares(pelagon:0.0) 

3/24 17:53:25 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@kephalos(pelagon:0.0) 

3/24 17:53:28 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@kephalos(pelagon:0.0) 

3/24 17:53:34 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@kephalos(pelagon:0.0) 

3/24 17:53:41 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@narcissus(pelagon:0.0) 

3/24 17:53:43 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@kephalos(pelagon:0.0) 

3/24 17:53:48 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@frodo(pelagon:0.0) 

3/24 17:53:54 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@polyhymnia(pelagon:0.0) 

3/24 1 7:54:00 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@kephalos(pelagon:0.0) 

3/24 17:54:09 (cdslmd) DENIED: VERILOG-XL v2.000 by veena@godzilla(192.216.l92.204:0.0) 

3/24 17:54:34 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@kephalos(pelagon:0.0) 

3/24 17:55: 12 (cdslmd) DENIED: VERILOG-XL vl .700 by rwo@mercury(pelagon:0.0) 

3/24 18:06:12 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@merope(pe1agon:0.0) 

3/24 18:06:42 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@frodo(pelagon:0.0) 

3/24 18:07:01 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@hera(pelagon:0.0) 

3/24 18:07:04 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@hera(pel agon: 0.0) 

3/24 18:07:10 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@hera(pelagon:0.0) 

3/27 10:05:59 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@mercury(pelagon:0.0) 

3/27 10: 15:39 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@hera(pelagon:0.0) 

3/27 10:15:41 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@narcissus(pelagon:0.0) 

3/27 10: 15:57 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@polyhymnia(pelagon:0.0) 

3/27 10:16:30 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ares(pelagon:0.0) 

3/27 10:16:45 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pelorus(pelagon:0.0) 

3/27 10:16:46 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pelorus(pelagon:0.0) 

3/27 10:18:31 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pegasus(pelagon:0.0) 

3/27 10:18:34 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pegasus(pelagon:0.0) 

3/27 10:18:40 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pegasus(pelagon:0.0) 

3/27 10:18:49 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pegasus(pelagon:0.0) 

3/27 10:18:57 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@merope(pelagon:0.0) 

3/27 10:19:06 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pegasus(pelagon:0.0) 

3/27 10:19:37 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ambiorix(pelagon:0.0) 

3/27 10:19:40 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pegasus(pelagon:0.0) 

3/27 10:19:41 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ambiorix(pelagon:0.0) 

3/27 10:19:46 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@ambiorix(pelagon:0.0) 

3/27 10:19:56 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ambiorix(pelagon:0.0) 

3/27 10:20:13 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ambiorix(pelagon:0.0) 

3/27 10:20:45 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pegasus(pelagon:0.0) 

3/27 10:20:47 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ambiorix(pelagon:0.0) 

3/27 10:21:01 (cdslmd) DENIED: VERILOG-XL vl,700 by fwo@hera(pelagon:0.0) 

3/27 10:21:01 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@kephalos(pelagon:0.0) 

3/27 10:21:03 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@mercury(pelagon:0.0) 

3/27 10:21:52 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ambiorix(pelagon:0.0) 

3/27 13:00:22 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@frodo(pelagon:0.0) 

3/27 13:02:59 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pelorus(pelagon:0.0) 

3/27 13:06:15 (cdslmd) DENIED: VERILOG-XL vl.700 by lwo@pegasus(pelagon:0.0) 

3/27 13:06:33 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@kephalos(pelagon:0.0) 

3/27 13:06:34 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@hera(pelagon:0.0) 

3/27 13:06:44 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@mercury(pelagon:0.0) 

3/27 13:07:21 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@ambiorix(pelagon:0.0) 

3/27 15:03:49 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pelorus(pelagon:0.0) 

3/27 15:34:03 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pelorus(pelagon:0.0) 

3/27 15:51:50 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pegasus(pelagon:0.0) 

3/28 10:43:10 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pelorus(pelagon:0.0) 

3/28 13:35:25 (cdslmd) DENIED: VERILOG-XL vl.700 by two@hera(pelagon:0.0) 

3/28 1 5:05:42 (cdslmd) DENIED: VERILOG-XL vl .700 by fwo@polyhymnia(pelagon:0.0) 

3/28 15:05:42 (cdslmd) DENIED: VERILOG-XL vl.700 by iwo@hera(pelagon:0.0) 

3/28 15:1 1:13 (cdslmd) DENIED: VERILOG-XL vl.700 by fwo@pegasus(pel agon: 0.0) 

This was in the last 5 days. 

Mostly this was Fred trying to run Celltest. 

I would say it's peaky, and we're talking about <$2000 (5% of $3 5k) 
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-hopper 
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Subject: 


From: 


Sent: 

To: 

Cc: 


Curtis Abbott [abbott@microunity.com] 
Wednesday, March 29, 1995 5:04 PM 
'tony' 

Craig Hansen; 'Graham Y. Mostyn"; John Moussouris 
FW: Thanks and Questions 


"tony" wrote (on Mar 29) : 
>>>>CURTIS 

I understand you are developing an OS and a compiler for your media 
processor (MP) . What is your OS like? You also said that you have 
developed a microkernel OS to run UNIX on your MP. You also mentioned that 
Windows NT is being ported on to MP. In these cases, what kind of 
performance do you expect to get out of your MP running UNIX or NT? 

We are currently working on 2 separate OS's for our mediaprocessor : a real-time 
microkernel intended to support certain kinds of small -memory applications, and an OSF 
port intended to support applications with larger memory, less cost sensitivity, and more 
reliance on traditional and/or pre-existing software. In understanding these, it is 
important to know that our mediaprocessor implementation is a 5 -way multiprocessor sharing 
a memory system -- a single datapath in which 5 instruction streams execute in round 
robin, each with separate registers, and communicating through the memory system and with 
the support of multiprocessor synchronization instructions. 

The OSF port will be most appropriate for products containing Mnemosyne DRAM and PCI 
controllers. We plan to modify the existing multiprocessor support in OSF to work with 
the shared memory model of our chip implementation. 

The microkernel is best suited to running a single application at a time, though it is 
capable of running more than one. It is designed to provide i/o support through device 
drivers, support for organizing computation through software threads of control, and 
support for minimally trusted applications through its use of the TLB and protected 
gateway features of the architecture. (Note that trust in this sense applies to potential 
maliciousness but perhaps even more importantly to poorly debugged code. The ability to 
develop code in a controlled, protected environment is a time-to-market enhancer that has 
been little appreciated in embedded systems, or even PC/Mac 
software . ) 

Generally speaking, the microkernel is designed to provide the kinds of support enumerated 
above but to stay out of the way as much as possible while doing so. For example, memory 
protection is arranged so that page mappings need never be changed (for to do so would 
decrease predictability and make real-time programming harder) . Also, the user- level 
interface to device drivers is through shared buffers; Unix- style i/o requires either an 
extra memory-to-memory copy or else page mapping. 

As to Windows NT, no port is currently underway, though negotiations are in progress. 

Performance under Unix or NT will be a fairly sensitive function of the kind of 
applications run under them and their disposition in the physical memory space. One 
interesting scenario would be to run Unix or NT applications in a single one of the 
multiprocessors and to run specialized, real-time media code in the others. The Euterpe 
design allows this to be done for many applications without memory system interference. 

I assume MPEG1 and MPEG2 decoding can be done realtime on your MP. 
Thus, 

this MP can be used for the ATV (U.S. all digfgital version of HDTV) set? 
Can MPEG1 and MPEG2 encoding also be done realtime? 

We have focused intensely on MPEG 2 MPML decoding. MPEG1 CIF decoding is a subset, which 
we can do easily. HDTV decoding is probably within our grasp, but we need to investigate 
memory bandwidths, worst -case use of B frames by the encoder, etc. We have not actually 
reduced MPEG encoding to practice. We have developed and evaluated a surprisingly fast 
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motion estimation algorithm, equivalent to exhaustive search. This makes us think 
broadcast quality MPEG 2 encoding is an objective worth trying for. 


Is your MP also suited for 3D CG rendering, etc? Can it be used as a 
virtual reality engine? 

The microkernel incorporates a 2D 24 -bit color graphics package with anti-aliased text and 
various other features. We have not seriously investigated 3D algorithms yet. Based on 
preliminary studies, the instruction set appears very suitable for rendering algorithms. 
Given that there is no floating point, it is somewhat less suitable for the geometry 
calculations that preface the rendering operations, but these are usually fewer in number 
anyway . 
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Subject: 


Sent: 

To: 

Cc: 


From: 


doi (Derek Iverson) 

Wednesday, March 29, 1995 6:53 PM 

'iimura'; 'gmo'; 'guarino'; 'jeffm'; 'gregg' 

'hestia' 

Software Bringup Meeting Minutes - March 29, 1995 


Software Bringup Meeting 


March 29, 1995 


Next Meeting: 


April 5 at 10:00 am. 


Attendees: guarino, gmo, jeffm, doi, gregg 


New Action Items 


Item: Is smux aliased to smas? 
Who: jeffm 
Status : New 


Item: Modify tests in diag tree to use tec instead of tgee 
Who: guarino, jeffm, doi 
Status : New 


03/29 Loretta has changed the diag tests to use tec instead 
of tgee but has not checked in the changes . 
Lisar wants these changes to be made after we are able to 
run the tests successfully using tgee . 

Review of Action Items 


Item: Can a single cylinder (in an exception "loop') lock out other 
cylinders? 
Who: jeffm 
Status: Done. 

03/08 Jeff needs to talk with mws. 
03/18 No progress. 

03/22 Jeff is going to add a note to verify.html mentioning that 
we need to investigate the behaviour of a bback/ exception 
to see if can cause other cylinders to be locked out. 

03/29 No progress. 


Item: Tests need to be written to verify performance issues 
Who: lisar, claseman 
Status: in progress. 

02/22 We need to flag performance problems as errors. 

Tests could be identified {and perhaps written) to measure 
and verify performance of the hardware for things like cache 
misses, tlb initialization, exceptions, etc. 

03/01 Lisar has started writing these tests. 

03/08 Work continues. 

03/15 Tim Claseman is assisting. 

03/22 We need to generate a list of tests that we think should be 
written 

first. Jeff suggested dcache fills, icache fills, dram and hermes 
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accesses . 

03/29 Tim has come a long way up the learning curve and is now focused 
on producing the first 4 tests that were requested. 


Item: Terp Feature Status 
Who : gmo 
Status : New 

03/29 Gmo reviewed the updated list. Here it is. 
Simulator to-do List 3-29-95 


o Holes in address spaces => machine checks 

- mostly done. 

o Address interleave 

- mostly done. 

o Reflect "forward progress" change in the hardware 

- complete and being tested, 
o Ifetch protection granulatiry 

- performance vrs accuracy tradeoff 
o Fetch intructions as octlets 

o Simulate Ifetch queue 

o Accuray wrt HW simulator's?) 

o Better latency model for Calliope accesses 

o Implement hardware configuration through Cerberus regs 

(SDRAM paramters?) 
o Checkpoints/Snapshots 
o Model PCI 

o hermes and cerberus timeout machine checks 

- question of whether they are supported 
o ability for terp to load hermes sections 

- not needed yet by verification group 


Suspended Items 


Item: Uhsnap code 
Who: sandeep, guarino 
Status : Suspended . 

02/15 The issue of restarting the hardware from an IKOS dump 

was discussed and the need for an architectural snap/unsnap 
facility was questioned. 

Since the meeting it has been re -discovered (jeffm wasn't there 
to remind us of an earlier decision) that we are planning on 
loading architectural state into an IKOS simulation and not 
from a total IKOS logic dump. 

We also determined that when it came time to run some 
of the larger tests (real-time benchmark) we would need 
the capability to start an IKOS simulation from an 
architectural dump anyhow. 
03/01 For the short term we are going to focus on a simpler 
approach for loading and running DVTs, the kernel, and 
kernel tests. This item will likely come back in April. 


Item: Refine remote debugging environment 
Who: sandeep 
Status: Suspended 

02/08 We have to decide how control (and state) is to be returned 

to the debug stub after a test runs. 
02/15 Sandeep is not going to have time to start on this for a while. 
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Item: Create performance test plan 
Who: jeffm, guarino 

Status: [11/3 0] No progress as focus is on functionality. 

We continue to run tests to help us compare terp vs hardware 
performance . 

We still need to put together the actual performance tests that 
need to be run on the hardware . 

Completed Items 


Item: Terp needs to model "guaranteed forward progress for cache miss* 

in the same fashion as the hardware does. 
Who: lisa 
Status: Done. 

03/01 Lisa has contacted mws and is implementing the same scheme 

used by the hardware . 
03/08 Still in progress. 
03/15 Progress continues. 

03/22 Ditto. Jeffm mentioned that cachenasty2 doesn't work with terp. 

03/2 9 Lisa has implemented fixes but is unable to get cachenasty2 to 

fail with the old simulator. Jeff and I were unable to reproduce 
the failure either. Lisa is going to check in the fixes and 
we are going to call this one done. 

Item: Determine what additional terp features are required 

(formally ""Status of Euterpe/Mnemo simulation') 
Who: gmo, jeffm 

Status: Replaced with new item (Terp Features Status) . 

02/08 Jeffm figured that in 2 - 3 weeks time there would be a need 

for terp/mnemo capability to support the verification effort. 

An issue was raised that this may not be enought time for the 

required additions to terp to be made. 
02/15 Gmo is to create a list of requested features for terp and 

then he and jeffm (and others?) are to review the list and 

determine what will be implemented by terp . 
02/22 Gmo is ready to circulate the list. 
03/01 Nothing new. 

03/08 Gmo has shown a group of people the list but will post it. 
03/15 Still pending. 
03/22 Ditto. 

03/29 Replaced with item "Terp Features Status' 

Item: Is unix test modified to work around the ltlb/gtlb enable stuff? 
who : i imur a , do i 
Status : New/Done 

03/29 doi talked to iimura before the minutes were complete. This 
modification has been made (and will be removed when the 
hardware fix is implemented) . 

Test Status and General Discussion 


More of the acceptance tests ran successfully on the latest BOM . 
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Subject: 


From: 
Sent: 
To: 
Cc: 


Loretta Guarino [guarino@microunity.com] 
Wednesday, March 29, 1995 9:34 PM 
'mediacom-software@microunity.com' 
'compiler@microunity.com' 
March 27 Benchmark Meeting 


We considered hardware configurations that we might have to work with in the coming 
months : 

Cronus only (August or September) 
Euterpe only (September?) 
Euterpe + Mnemo ( ? ? ) 
Euterpe + Calliope (September? ) 

It seems likely that our initial system will be either a Cronus or Euterpe. The major 
differences between these two systems would be speed. Most likely Euterpe won't be air- 
bridged, so it won't run at 1GHz. Bill H. says at current power a non- air-bridged Euterpe 
should run at 4 00MHz. 

Rev 0 Calliope will be processed before either Euterpe or Mnemo, so based on current 
progress it looks like a non-air-bridged Calliope with some functionality might be 
available as soon as Euterpe. 

For a Cronus or Euterpe system, we'll develop versions of the Digital TV and maybe the 
Analog TV applications that don't use calliope. They would load initial data into DRAM and 
write a few frames worth of output into DRAM. This will let us test Euterpe first, before 
we take on the added complexity of Calliope. 

For a Euterpe+Mnemo system, we'll modify this basic Digital TV application to write video 
output to a VGA buffer; this would require adding support for the PCI graphics card to the 
Microkernel . 

For a Euterpe+Calliope system, we would focus on testing Calliope. In addition to the 
existing calliope diagnostics and Microkernel tests, we'll write simple tests to drive 
audio-out and video-out and expand the IR tests. We can also look into bypassing part of 
Calliope and receiving baseband QAM, so we can start testing our QAM code even if the RF 
portion of Calliope isn't working. We should be able to run the UI benchmark on this 
system, and the RF QAM receiver. For bring-up, we are assuming the availability of 
accurate clock sources . 

We need to look at all our tests with an eye on how to make them work on a system with a 
much slower clock than we have been planning for. 

As much as possible, we'd like to avoid having to completely restructure code just for 
testing in this environment. 

The non- calliope tests can probably just run more slowly. It may be possible to develop 
tests that use a slower Euterpe+Calliope to demod a lower baud- rate signal. Curtis has 
talked with Graham who is investigating the technical issues. 
Curtis will organize a separate meeting to investigate QAM. 

Some general decisions: 

1) We'll remove DLWS from the Digital and Analog TV benchmarks for now; we aren't using 
much of its functionality, and it should be easier to fit the TV benchmarks without it. 
This should permit Tom to focus on support for the UI benchmark. The video-out code will 
probably have to be restructured to permit us to remove DLWS. 

2) We will need differently configured 

Microkernels for each of the benchmarks (with and without calliope support, with varying 
sets of devices, etc.) . We need to look at what Makefile changes are needed to make this 
is easy as possible. 

We'd like to minimize the number of modules that have to be compiled separately for 
different configurations; how will trim_stack affect this? 
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From: 
Sent: 
To: 

Subject: 


Gregg Kellogg [gregg@hts.microu nity.com] 
Wednesday, March 29, 1995 10:04 PM 
'fur' 

terp changes 


I tried the modifications you suggested. It initially seemed to work, but now I'm still 
in the situation where the trace buffer overflows. 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg@microunity.com 
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From: 


tor 


Subject: 


To: 


Sent: 


Cc: 


Wednesday, March 29, 1995 1 1 :05 PM 
•billz (Bill Zuravleff)' 
'geert (Geert Rosseel)' 
Re: dr doesn't converge 


Follow Up Flag: Follow up 
Flag Status: Red 

Bill Zuravleff wrote (on Wed Mar 29): 
Tim, 

Re: dr doesn't converge 

I can't account for the differences in my run versus the run in 
.../s41/euterpe-snapshot/... but for that run, there are several 
nets in the lowest quadrant which don't route because all of the 
veritical routing resources have been used up. A way to fix this 
might be to introduce a column of spacer cells which keep the real 
cells further apart and create more, local veritical routing 
resources. Do you suggest I try this? 

I think what surprised me most was just how ragged the right side was 
at the top in the early passes, and it seemed to me like many passes 
were needed before pifpack stopped moving things around. I don't know 
what's different in the snapshot from /u/chip, since the snapshot was 
updated from the BOM at the weekend. I think we need to understand it 
in the /s41 version. Do you have your local proteus pointing at the 
snapshot, or /u/chip? 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Wednesday, March 29, 1995 1 1:05 PM 

'billz (Bill Zuravleff)' 

'geert (Geert Rosseel)' 

Re: dr doesn't converge 


Bill Zuravleff wrote (on Wed Mar 29) : 
Tim, 

Re: dr doesn't converge 

I can't account for the differences in my run versus the run in 
... /s41/euterpe- snapshot/ .. . but for that run, there are several 
nets in the lowest quadrant which don't route because all of the 
veritical routing resources have been used up. A way to fix this 
might be to introduce a column of spacer cells which keep the real 
cells further apart and create more, local veritical routing 
resources. Do you suggest I try this? 

I think what surprised me most was just how ragged the right side was at the top in the 
early passes, and it seemed to me like many passes were needed before pifpack stopped 
moving things around. I don't know what's different in the snapshot from /u/chip, since 
the snapshot was updated from the BOM at the weekend. I think we need to understand it in 
the /s41 version. Do you have your local proteus pointing at the snapshot, or /u/chip? 


Tim 
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From: lisar (Lisa Robinson) 

Sent: Thursday, March 30, 1995 12:24 AM 

To: 'cadettes'; 'sysadm' 

Subject: /bin/hostname? 

What does this mean? 

Usar@trex /n/nosferatu/s2/euterpe/stb/stand/diag419 % gmake HWSIM=1 CHIPROOT=/n/nosferatu/s2/euterpe 
gmake: execve: /bin/hostname: No such file or directory 

VVpWW(WHWWXWOWHYX0XHY Y8YPY YY(YHY'YxZZ0Z@ZPZZZ8Zh[gmake: execve: /usr/!ocal/bin/hostid: No 
such file or directory 

W/n/nosferatu/s2/euterpe/tooIs/vendor/soft/stb/bin/tgcc -DDEBUG_LEVEL_ 1 -DNO_CALLIOPE -DSHORT - 
MDupdate .depend -I.Vlib -g -02 -c instr_main.c -o instr_main_l .o 

Lisa R. 
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From: wampler (Kurt Wampler) 
Sent: Thursday, March 30, 1995 12:28 AM 
To: 'cadettes'; 'lisar'; 'sysadm' 
Subject: Re: /bin/hostname? 

lisar writes: 


>What does this mean? 

> 

>lisar@trex /n/nosferatu/s2/euterpe/stb/stand/diag 419 % gmake HWSIMH CHIPROOT=/n/nosferatu/s2/euterpe 
>gmake: execve: /bin/hostname: No such file or directory 

>VVpWW(WHWWXWOWHYXOXHY Y8YPY l YY(YHY , YxZZ0Z@ZPZZZ8Zh [gmake: execve: /usr/local/bin/hostid: No 
such file or directory 

>W/n/nosferatu/s2/euterpe/tools/vendor/soft/stb/bin/tgcc -DDEBUG LEVELJ -DNO_CALLIOPE -DSHORT - 
MDupdate .depend -I.Vlib -g -02 -c instr_main.c -o instrmainl.o 


At first glance it looks like the Makefile you're running is designed to work 
only on the SUN platform. I believe this is true of most of our Makefiles. 

It seems to be trying to run "hostname" from /bin, and "hostid" from 
/usr/local/bin. On trex, these programs are found under: 

/usr/ucb/hostnam e 
/usr/ucb/hostid 

The simple thing is probably to go back to a SPARC- 10 machine and run it 
there. 

-Kurt 
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From: tbr 

Sent: Thursday, March 30, 1995 12:55 AM 

To: 'hopper (Mark Hofmann)' 

Cc: 'lisar' 

Subject: verilog?- last chance... 

Follow Up Flag: Follow up 

Flag Status: Red 


Mark Hofmann wrote (on Wed Mar 29): 


tim, 

should we purchase another copy of verilog at the 15% discount? 
we probably need to act this week, if i don't hear from you i asusme 
the asnwer is no. 

Sorry, mark, kept meaning to respond on this one. We are going 
through a peak right now, which I think will drop off shortly once 
Euterpe is finally behind us. Is there a logfile anywhere that shows 
the usage? I know lisar has failed to get a license a few times, but 
usage is peaky. If we are near the limint much of the time during the 
day, we should do it, if we typically have a couple of spares and 
only hit the limit occasionally I'd hold off. $35K is a lot, and 
the downside is really only the delta discount. 

Tim 
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From: geert (Geert Rosseel) 

Sent: Thursday, March 30, 1 995 1 : 1 0 AM 

To: 'dickson'; 'tbr' 

Subject: New Euterpe top-level 


Hi, 

I am a bit confused with the latest Euterpe top-level. I am doing the 
placement now but things are a bit messed up around the rg-gf-es interface. 
I am kind of stuck here, gf sticks out quite a bit to the left of the 
clock spar to the left of rg and clashes in a major way with es. 

Geert 
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From: tbr 

Sent: Thursday, March 30, 1995 1:14 AM 

To: 'geert (Geert Rosseel)' 

Cc: 'dickson' 

Subject: New Euterpe top-level 

Follow Up Flag: Follow up 

Flag Status: Red 


Geert Rosseel wrote (on Wed Mar 29): 


Hi, 

I am a bit confused with the latest Euterpe top-level. I am doing the 
placement now but things are a bit messed up around the rg-gf-es interface. 
I am kind of stuck here, gf sticks out quite a bit to the left of the 
clock spar to the left of rg and clashes in a major way with es. 

Rich just mentioned he had some more changes in es placement, and I 
see the BOM has been updated to 82 since I built it. Could this be 
the problem? 

Tim 
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Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Thursday, March 30, 1995 1:14 AM 


'geert (Geert Rosseel)' 
'dickson' 


Subject: 


New Euterpe top-level 


Geert Rosseel wrote (on Wed Mar 29) : 


Hi, 


I am a bit confused with the latest Euterpe top-level. I am doing the 
placement now but things are a bit messed up around the rg-gf-es interface. 

I am kind of stuck here, gf sticks out quite a bit to the left of the 
clock spar to the left of rg and clashes in a major way with es. 

Rich just mentioned he had some more changes in es placement, and I see the BOM has been 
updated to 82 since I built it. Could this be the problem? 


Tim 
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From: geert (Geert Rosseel) 

Sent: Thursday, March 30, 1995 1:17 AM 

To: W 

Cc: 'dickson' 

Subject: Re: New Euterpe top-level 

Well, gf seems to have grown substantially, was there some logic added there 
or something. It is quite big now. 

Geert 
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Sent: 

To: 

Cc: 


Subject: 


From: 


tbr 

Thursday, March 30, 1995 1:21 AM 
'geert (Geert Rosseel)' 
'dickson' 

Re: New Euterpe top-level 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Wed Mar 29): 

Well, gf seems to have grown substantially, was there some logic added there 
or something. It is quite big now. 

No change that I'm aware of. Rich, do you know what changed? 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Thursday, March 30, 1995 1:21 AM 
'geert (Geert Rosseel)' 
'dickson' 

Re: New Euterpe top-level 


Geert Rosseel wrote (on Wed Mar 29) : 

Well, gf seems to have grown substantially, was there some logic added there 
or something. It is quite big now. 

No change that I'm aware of. Rich, do you know what changed? 

Tim 
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From: 
Sent: 
To: 

Subject: 


dickson (Richard Dickson) 
Thursday, March 30, 1995 2:06 AM 
'geeif; 'tbr' 
datat path 


tim and geert 

i'm confused also, i'm not sure what versions you have, 
i fired off my last releasebom an hour ago. since all my releaseboms failed this mornong i 
cant be sure that you got all my latest pirn files. 

could my top level level example not be powering up as geerts is. i'm running my top 
level route now. its past the gplace step. 

you can look at the rich_euterpe-iter placement in my bsrc/gards dir. 


dickson 
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To: 


Sent: 


Subject: 


Cc: 


From: 


tbr 

Thursday, March 30, 1995 4:45 PM 

■dbulfer' 

'woody' 

Euterpe module power connector 


Follow Up Flag: Follow up 
Flag Status: Red 

It appears the 6 pin power connector on the Euterpe module 
has 3 pins assigned to each of gnd and 3.3V. Since we need the option 
of plugging a 5V cronus module into the the same backplane slot 
we need 5 V assigned on this connector even though it will not be 
hooked up on this module. Can we reassign to 2 pins each on gnd, 
3.3V, and 5V? 


Tim 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 30, 1995 4:52 AM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/mc BOM 65.0 initiated by dickson completed @ Thu Mar 3 0 
01:51:43 PST 1995 with exit status 0.. chip 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 
Thursday, March 30, 1995 7:11 AM 
'Geert Rosseel' 
Re: spacerln.awk parse error 


Geert Rosseel writes: 

I am running cc and I get this : 

gawk : /n/ghidra/ s3 /geert /euterpe/ tools/ src/pim2pof / spacer In . awk : 10 6 : 
printf ( "Can' t find an anchor for : \n" , name [i] ) >> spacers . funny 

gawk : /n/ghidra/s3 /geert/euterpe/tools/src/pim2pof /spacerln . awk : 106 : 
A parse error 


The data is in /n/ghidra/s3/geert/euterpe/verilog/bsrc/cc 
makefile output is in make. out 
*pif and *pim files are in gards directory- 


Yes. I just checked in a fix. 
Please try again. 

(We installed a new verison of gawk) 


-mark 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 30, 1995 9:19 AM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/rg BOM 108.0 initiated by dickson completed @ Thu Mar 30 
06:18:52 PST 1995 with exit status 0.. chip 
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From: 
Sent: 
To: 


Subject: 


Kevin Peterson [khp@microunity.com] 
Thursday, March 30, 1995 1:15 PM 

, yam@microunity.conY; *pu ri@microunity.com'; 'rhunt@microunity.com'; 
'abbott@microunity.com' 

forwarded message from Mail Delivery Subsystem 


Sorry, I screwed up the CC line. 
-Kevin 


From: khp (Kevin Peterson) 

Message-Id: <199503301812 . SAA122 96@spirot .microunity . com . > 

To: age (Alan Corry) 

Cc : yam . rhunt . puri . abbott 

Subject: what's the equalizer used for ? 

In-Reply-To : <1995033018 02 . KAA07732@narcissus .microunity . com> 
References : <199503301802 . KAA07732@narcissus . microunity . com> 


> I noticed that only 32 taps of the equalizer are being used. Does NTSC 

> use the full 64 taps ? On the next rev it might be possible to get a 

> considerable power reduction if we only need a 32- tap FIR by sharing 

> computes between the equalizer and resampler. 

I'm pretty sure Ron is using all 64 taps to implement his VSB filter but I don't know if 
it's a requirement. We're only using 32 for QAM because we don't have enough cycles on 
euterpe to update 64 in real-time at the decimated rates we've chosen. Anyway, using only 
32 is definitely a possibility but the performance we've measured is marginal, especially 
for longer echoes. This is a design choice that deserves a lot of discussion - we 
understand all of the tradeoffs so it really depends on what performance we need for the 
target application. 


-Kevin 
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From: Potatoe Chip [chip@rhea] 

Sent: Thursday, March 30, 1995 2:12 PM 

To: 'Potatoe Chip' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/es BOM 83.0 initiated by dickson completed @ Thu Mar 3 0 
11:11:26 PST 1995 with exit status 0.. chip 
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From: wingard (Drew Wingard) 

Sent: Thursday, March 30, 1995 3:11 PM 

To: 'bill'; 'lisar' 

Cc: 'geert'; 'for' 

Subject: Re: CMOS activity 


Lisa wrote: 

> William Herndon wrote {on Thu Mar 30) : 
> 

> The idea of events divided by the number of cycles of simulation 
sounds 

> like the right metric. Is there an official name for this?? 

> I think having this number is essential . It is key to being able to 

> predict our actual power dissipation. 

> I am also trying to predict the actual power supply noise, so I 

> need 
to 

> be able to make some sort of a model of the circuit that is driving 
the 

> transients. 

> Hot spots: right now we assume lu gate width for 10u2 of layout 

> area, 
and 

> from that we get the total gate width possible in some layout area. 
We also 

> assume 1/4 of that gate width is switching output load at any one 
time 

> and use the peak current for that gate width to predict the peak 
current 

> in any area. At 150 watts, this gives us a peak current for any given 

> area that is 80 times the average current. 
> 

> I've looked at 7 tests covering 3 types and it looks like a good 

> number is 42000. (Now I am running cerberus artificially fast.) 

Wow. Given approx, 80000 Gards-visible nets, that's amazingly close to a switching 
probability of one-half . This is a *scary* microarchitecture for CMOS. 

I wonder what fraction of those events are "useful 11 ... (i.e. convey data that is 
used) 

So here's a back-of- the- envelope calculation for the switching power: 

Power = (Total Wire Cap .)* (Supply Voltage A 2 )* (Switching Frequency) Total Wire Cap: 

(from Euterpe. . . ) 

Average net length : . 6mm 

Number of nets: 80K 

Capacitance /mm: 13 0fF (we use *some* M2) 
(Cronus changes) 

Average net length: .6mm * 1.5 

I consider 1.5 to be a lower bound: while the wire pitch is 2.4x worse, 
the number of wires is less and the CMOS gates take relatively less 
space than their BiCMOS counterparts 

Number of nets: 8 OK * .6 

Again, .6 is probably a lower bound. Converting all differential 
signals to single-ended at the top (hierarchical) level of euterpe.v 
gives about .55, and these wires are most likely to be differential, 
due to their length. 

Capacitance /mm: 300fF 
Supply Voltage: 5V 

Switching Frequency: 4 0 0MHz * .25 

.5 transition probability is one signal cycle every four clock cycles Switching 

Power : 

32.4 Watts 
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This is in addition to the clock power, which we've estimated at: 
(50K flops) * (lOOfF/f lop) * (25V A 2) * (400MHz) = 50 Watts but the clock driver has 
substantially higher power due to its low skew and fast edge requirements. I think Bill's 
latest estimate was that to deliver 18A into the load required 28A total current, so I'll 
call 28/18 a 1 . 5x hit in power. 

That would make our latest Cronus power estimate: 

32.4 + (50)*(1.5) = 107W 
not including custom blocks or the I/O. 

So maybe we can hit our 150W target after all... 

Drew 
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From: 
Sent: 
To: 

Subject: 


chip (Potatoe Chip) 

Thursday, March 30, 1995 5:31 PM 

'geert' 

output of euterpe/verilog/bsrc/cc/.checkoutrc 


The output from euterpe/verilog/bsrc/cc/ . checkoutrc is 216k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/geert .tomato. 3583 . euterpe-verilog-bsrc-cc 

(which is accessible from all machines) . This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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From: dbulfer (David Bulfer) 

Sent: Thursday, March 30, 1995 6:16 PM 

To: Tim B. Robinson' 

Cc: 'woody (Jay Tomlinson)' 

Subject: Re: Euterpe module power connector 


> 
> 

> It appears the 6 pin power connector on the Euterpe module 

> has 3 pins assigned to each of gnd and 3.3V. Since we need the option 

> of plugging a 5 V cronus module into the the same backplane slot 

> we need 5V assigned on this connector even though it will not be 

> hooked up on this module. Can we reassign to 2 pins each on gnd, 
>3.3V, and 5V? 

> 

>Tim 

> 

We are looking into it Specifically, we are looking at 2 pins for 
common 3V/5V gnd, 2 pins for 5V and 2 pins for 3V. A single contact 
is rated for 30 A, but that is not the same as working well at 30 A. 
Vijay has been assigned the task of analyzing how well 2 pins will 
work. He has promised me that he will hav an answer today. 


David 
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From: dbulfer (David Bulfer) 

Sent: Thursday, March 30, 1995 6:19 PM 

To: 'Patricia Mayer' 

Cc: 'woody (Jay Tomlinson)'; 'howard (Howard Cowles)'; 'tbe (Tom Eich)'; 'Philip Wong'; Tim B. 
Robinson'; 'Patricia Mayer'; 'pandora' 

Subject: Re: Euterpe Module Review 

> 

> There will be a Euterpe-Pandora Module design review tomorrow, Thursday 

> March 31 at 3:00 in the Engineering conference room. 

> 

> Please plan to attend 

> Thanks 

> -Pattie 

> 

1 realize that it's daylight saving time this weekend, but it's only 
one hour ahead, not one day ;=)... 

I assume you mean Friday? If so, 3pm is the scheduled Pandora 
meeting (that many of your invitees will be at.) 

David 
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From: pmayer (Patricia Mayer) 

Sent: Thursday, March 30, 1995 6:42 PM 

To: 'yves'; 'dane'; 'rmm'; 'rich'; 'arya'; 'noel'; 'woody'; 'tbr'; 'wayne' 

Cc: 'dan'; 'graham'; 'hestia' 

Subject: hestia review meeting notes 


This was a review meeting primarily of the 4 new schematic sheets for the digital Euterpe 
area, named mainbdl. 

page 1 *The smart card should be connected to digital ground. Woody 

*The PLL pins should have a circuit of 1 inductor, 1 bead and 2 
capacitors much like the circuit on syextosc page 1.1. Rich 
*****This will also effect the Euterpe -Pandora module* **Woody 

page 2 *There are 2 power_group statements on T34U2, T32U2 . Woody 

page 3 *Lots of question marks on this page??? Arya 

♦General practice to show pin numbers on transistors/pnp . All 


Reviewed and identified PR's to be closed: 

1771 - Woody please verify 

1772 

1777 

1792 

1809 

18 61 - Woody please verify 

1901 

1909 

1934 

1945 

1946 

2001 

2007 

2009 

2010 

2012 

2031 

2035 

2036 

Also PR's 1914 and 1950 are being closed for some unknown reason... 
Something 

about they are closed for reworking the last rev (2) and assumed it will be fixed (by way 
of the new tool) on the new board. An ECO will flag for this to still be checked on the 
new board. 

Please let me know if you have additional comments. 

Thanks 
-Pattie 
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Subject: 


Sent: 

To: 

Cc: 


From: 


albers (Daniel Albers) 

Thursday, March 30, 1995 6:45 PM 

'Patricia Mayer' 

•yves (Jean-Yves Michel)'; 'dane (Dane Snow)'; 'rmm (Richard Meller)'; 'rich (Rich McCauley)'; 
'arya (Arya Behzad)'; 'noel (Noel Verbiest)'; 'woody (Jay Tomlinson)'; 'tbr (Tim B. Robinson)'; 
'wayne (Wayne Freitas)'; 'dan'; 'graham (Graham Y. Mostyn)'; 'hestia' 
Re: hestia review meeting notes 


> the words of Patricia Mayer: 
> 

> This was a review meeting primarily of the 4 new schematic sheets for 
the 

> digital Euterpe area, named mainbdi. 


> page 3 *Lots of question marks on this page??? Arya 

There appears to be something in the plot script which is causing 
this. The values are fine in the actual schematics. 
I am looking into fixing the plotting. 


Daniel Albers albers@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 

It can be made into a monster if we all pull together as a team. . . 


> 


[snip] 
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Subject: 


Sent: 

To: 

Cc: 


From: 


pmayer (Patricia Mayer) 

Thursday, March 30, 1995 7:01 PM 

'd buffer'; 'woody'; 'howard'; 'tbe 1 ; 'philip'; 'tbr 1 

'pmayer'; 'pandora' 

New Euterpe PCB Review 


Sorry, I didn't mean to extend everyones week by re- living Thursday. Ha!? 

Thanks David for informing me of the meeting conflict. I've rescheduled the Engineering 
conference room for Monday April 3rd at 10:00AM for the Pandora Euterpe PCB design review. 
Please let me know if there is another conflict. 

New edits have come up: 

1) Tooling holes are to be added. 

2) New circuit for PLL pins. 

The vias for diferential pairs have been moved, (possible .5 max length 
difference) 


Thanks 
-Pattie 
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From: Tom Eich [tbe@microunity.com] 
Sent: Thursday, March 30, 1995 7:09 PM 
To: 'pmayer (Patricia Mayer)' 
Cc: *d buffer 1 ; 'woody'; 'howard'; 'phi lip'; 'tor' 
Subject: Re: New Euterpe PCB Review 

>Sorry, I didn't mean to extend everyones week by re-living Thursday. Ha!? 

> 

>Thanks David for informing me of the meeting conflict. I've rescheduled 
>the Engineering conference room for Monday April 3rd at 10:00AM for the 
>Pandora Euterpe PCB design review. Please let me know if there is another 
>conflict. 

> 

>New edits have come up: 

>1) Tooling holes are to be added. 

>2) New circuit for PLL pins. 

> 

>The vias for diferential pairs have been moved, (possible .5 max length 
>difference) 

> 

>Thanks 
>-Pattie 

Just to clarify, I have only supplied outline criteria and that having to 
do with the Euterpe and SDRAM areas. There are still features such as 
slots and hole to be placed outside the trace and component areas, and I am 
working on completing that design for early next week, but the layout we 
review Monday won't yet have those features in it. Does anyone have a 
problem with reviewing what we will have done by Monday (traces and 
components and pcb outline)? 

-Tom 


Tom Eich J tbe@microunity.com 

MicroUnity Systems Engineering, Inc.| 
255 Caspian Dr. Sunnyvale, CA 94089 | 
(408)734-8100, (408)734-8136 fax | 
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From: 
Sent: 
To: 

Subject: 


chip (Potatoe Chip) 

Thursday, March 30, 1995 7:25 PM 

'geeif 

output of euterpe/verilog/bsrc/at/.checkoutrc 


The output from euterpe/verilog/bsrc/at/ . checkoutrc is 200k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/geert .nosferatu. 19945 .euterpe-verilog-bsrc-at 

(which is accessible from all machines) . This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 1. 
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From: 
Sent: 


tbr 


Thursday, March 30, 1995 10:36 PM 
'wingard (Drew Wingard)' 
•bill'; 'geert'; 'lisar' 
Re: CMOS activity 


To: 


Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Drew Wingard wrote (on Thu Mar 30): 
Wow. Given approx. 80000 Gards-visible nets, that's amazingly close to 
a switching probability of one-half. This is a * scary* microarchitecture 
for CMOS. 

Let's not get too scared just yet. There are far more "primitive" 
gates on the simulator than real gates, so we need to factor that in. 
Id guess 2:1 for that. 

I wonder what fraction of those events are "useful"... (i.e. convey data that is 
used) 

At a wild guess, 20%. 

So here's a back-of-the-envelope calculation for the switching power: 
Power = (Total Wire Cap.)* (Supply Voltage A 2)*(Switching Frequency) 
Total Wire Cap: 

(from Euterpe...) 

Average net length: .6mm 

Number of nets: 80K 

Capacitance/mm: 130fF (we use *some* M2) 

(Cronus changes) 

Average net length: ,6mm * 1 .5 

I consider 1 .5 to be a lower bound: while the wire pitch is 2.4x worse, 
the number of wires is less and the CMOS gates take relatively less 
space than their BiCMOS counterparts 

Number of nets: 80K * .6 

Again, .6 is probably a lower bound. Converting all differential 
signals to single-ended at the top (hierarchical) level of euterpe.v 
gives about .55, and these wires are most likely to be differential, 
due to their length. 

Capacitance/mm: 300fF 
Supply Voltage: 5V 
Switching Frequency: 400MHz * .25 

.5 transition probability is one signal cycle every four clock cycles 
Switching Power: 

32.4 Watts 

This is in addition to the clock power, which we've estimated at: 

(50K flops)*(100fF/flop)*(25V A 2)*(400MHz) = 50 Watts 

but the clock driver has substantially higher power due to its low skew and 

fast edge requirements. I think Bill's latest estimate was that to deliver 

18A into the load required 28A total current, so I'll call 28/18 a 1.5x hit 

in power. 
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That would make our latest Cronus power estimate: 

32.4 + (50)*(1.5)= 107W 
not including custom blocks or the I/O. 

So maybe we can hit our 150W target after all... 

So given this data the inefficiency of having a majority of nodes 
switch without carrying useful data could well be elipsed by the clock 
overhead. 

Tim 
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From: tbr {Tim B. Robinson) 

Sent: Thursday, March 30, 1995 10:36 PM 

To: 'wingard (Drew Wingard)' 

Cc: 'bill'; 'geerf; 'lisar' 

Subject: Re; CMOS activity 


Drew Wingard wrote (on Thu Mar 30) : 

Wow. Given approx. 80000 Gards-visible nets, that's amazingly close to 
a switching probability of one-half. This is a *scary* microarchitecture 
for CMOS. 

Let's not get too scared just yet. There are far more "primitive" 
gates on the simulator than real gates, so we need to factor that in. 
Id guess 2:1 for that. 

I wonder what fraction of those events are "useful"... (i.e. convey data that is 
used) 

At a wild guess, 20%. 

So here's a back- of- the -envelope calculation for the switching power: 
Power = (Total Wire Cap .)* (Supply Voltage A 2) * (Switching Frequency) 
Total Wire Cap: 

(from Euterpe...) 

Average net length: ,6mm 

Number of nets: 80K 

Capacitance/mm: 13 0fF (we use *some* M2) 
(Cronus changes) 
Average net length: .6mm * 1.5 

I consider 1.5 to be a lower bound: while the wire pitch is 2.4x worse, 
the number of wires is less and the CMOS gates take relatively less 
space than their BiCMOS counterparts 
Number of nets: 8 OK * .6 

Again, .6 is probably a lower bound. Converting all differential 
signals to single-ended at the top (hierarchical) level of euterpe.v 
gives about .55, and these wires are most likely to be differential, 
due to their length. 
Capacitance /mm: 3 0 0fF 
Supply Voltage: 5V 
Switching Frequency: 4 0 0MHz * .25 

.5 transition probability is one signal cycle every four clock cycles 
Switching Power: 
32.4 Watts 

This is in addition to the clock power, which we've estimated at: 
(50K flops) * (lOOfF/f lop) * (25V A 2) * (400MHz) = 50 Watts 

but the clock driver has substantially higher power due to its low skew and 
fast edge requirements. I think Bill's latest estimate was that to deliver 
18A into the load required 28A total current, so I'll call 28/18 a 1 . 5x hit 
in power. 

That would make our latest Cronus power estimate: 

32.4 + (50) * (1.5) = 107W 
not including custom blocks or the I/O. 

So maybe we can hit our 150W target after all. . . 

So given this data the inefficiency of having a majority of nodes switch without carrying 
useful data could well be elipsed by the clock overhead. 

Tim 
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From: tbr 

Sent: Thursday, March 30, 1995 10:40 PM 

To: 'dbulfer (David Bulfer)' 

Cc: 'howard (Howard Cowles)'; 'pandora'; 'philip (Philip Wong)'; 'Patricia Mayer'; 'Patricia 

Mayer'; 'Tom Eich'; 'Jay Tomlinson' 

Subject: Re: Euterpe Module Review 

Follow Up Flag: Follow up 

Flag Status: Red 


David Bulfer wrote (on Thu Mar 30): 

I realize that it's daylight saving time this weekend, but it's only 
one hour ahead, not one day ;=)... 

I assume you mean Friday? If so, 3pm is the scheduled Pandora 
meeting (that many of your invitees will be at.) 

Yes. Can we hold this review at 2 instead? 

Tim 
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Subject: 


From; 
Sent: 
To: 
Cc: 


tbr (Tim B. Robinson) 

Thursday, March 30, 1995 10:40 PM 

'dbulfer (David Buffer)' 

'howard (Howard Cowles)'; 'pandora'; 'phi lip (Philip Wong)'; 'pmayer (Patricia Mayer)'; 'Patricia 
Mayer'; 'tbe (Tom Eich)'; 'woody (Jay Tomlinson)' 
Re: Euterpe Module Review 


David Bulfer wrote (on Thu Mar 30) : 

I realize that it's daylight saving time this weekend, but it's only 
one hour ahead, not one day ;=) ... 

I assume you mean Friday? If so, 3pm is the scheduled Pandora 
meeting (that many of your invitees will be at.) 

Yes. Can we hold this review at 2 instead? 

Tim 
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From: tbr 

Sent: Thursday, March 30, 1995 11:05 PM 

To: 'pmayer (Patricia Mayer)' 

Cc: 'dbulfer'; 'howard'; 'pandora'; 'philip'; 'pmayer'; 'toe'; 'woody' 

Subject: New Euterpe PCB Review 
Follow Up Flag: Follow up 

Flag Status: Completed 

Patricia Mayer wrote (on Thu Mar 30): 

Sorry, I didn't mean to extend everyones week by re-living Thursday. Ha!? 

Thanks David for informing me of the meeting conflict I've rescheduled 
the Engineering conference room for Monday April 3rd at 10:00AM for the 
Pandora Euterpe PCB design review. Please let me know if there is another 
conflict. 

New edits have come up: 

1) Tooling holes are to be added. 

2) New circuit for PLL pins. 

The vias for diferential pairs have been moved, (possible .5 max length 
difference) 

There is also a problem with the power connector. David is driving 
this. The problem is the backplane also needs to provide 5V for the 
Cronus module, even thouth the Euterpe module would ignore it. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Thursday, March 30, 1995 11:05 PM 

'pmayer (Patricia Mayer)' 

'dbulfer'; 'howard'; 'pandora 1 ; 'philip'; 'pmayer'; 'toe'; 'woody' 
New Euterpe PCB Review 


Patricia Mayer wrote (on Thu Mar 30) : 


Sorry, I didn't mean to extend everyones week by re-living Thursday. 


Ha!? 


Thanks David for informing me of the meeting conflict. I've rescheduled 
the Engineering conference room for Monday April 3rd at 10:00AM for the 
Pandora Euterpe PCB design review. Please let me know if there is another 
conflict . 

New edits have come up: 

1) Tooling holes are to be added. 

2) New circuit for PLL pins. 

The vias for diferential pairs have been moved, (possible .5 max length 
difference) 

There is also a problem with the power connector. David is driving this. The problem is 
the backplane also needs to provide 5V for the Cronus module, even thouth the Euterpe 
module would ignore it . 


Tim 
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From: tbr 

Sent: Thursday, March 30, 1 995 1 1 :07 PM 

To: Tom Eich' 

Cc: 'dbulfer'; 'howard'; 'philip'; 'pmayer (Patricia Mayer)'; 'woody' 

Subject: Re: New Euterpe PCB Review 
Follow Up Flag: Follow up 

Flag Status: Red 


Tom Eich wrote (on Thu Mar 30): 

>Sorry, I didn't mean to extend everyones week by re-living Thursday. Ha!? 

> 

>Thanks David for informing me of the meeting conflict. I've rescheduled 
>the Engineering conference room for Monday April 3rd at 1 0:00AM for the 
>Pandora Euterpe PCB design review. Please let me know if there is another 
>conflict. 

> 

>New edits have come up: 

>1) Tooling holes are to be added. 

>2) New circuit for PLL pins. 

> 

>The vias for diferential pairs have been moved, (possible .5 max length 
>difference) 

> 

>Thanks 
>-Pattie 

Just to clarify, I have only supplied outline criteria and that having to 
do with the Euterpe and SDRAM areas. There are still features such as 
slots and hole to be placed outside the trace and component areas, and I am 
working on completing that design for early next week, but the layout we 
review Monday won't yet have those features in it. Does anyone have a 
problem with reviewing what we will have done by Monday (traces and 
components and pcb outline)? 

I'm sure there will be issues arising from looking at what we have 
(I'm aware of a couple of things already), so we should not hold off 
any longer. 

Tim 
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From: tbr 

Sent: Thursday, March 30, 1 995 1 1 :25 PM 

To: 'dbulfer (David Bulfer)'; 'howard (Howard Cowles)'; 'pandora'; 'Philip Wong'; 'Patricia Mayer'; 

'Patricia Mayer"; Tom Eich'; 'Jay Tomlinson' 

Subject: Re: Euterpe Module Review 

Follow Up Flag: Follow up 

Flag Status: Red 


Tim B. Robinson wrote (on Thu Mar 30): 

I assume you mean Friday? If so, 3pm is the scheduled Pandora 
meeting (that many of your invitees will be at.) 

Yes. Can we hold this review at 2 instead? 

OK, forget that suggestion. I see it's been rescheduled to Monday. 

Tim 
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From: 
Sent: 
To: 


Subject: 


tbr (Tim B. Robinson) 

Thursday, March 30, 1995 11:25 PM 

'dbulfer (David Bulfer)'; 'howard (Howard Cowles)'; 'pandora'; 'philip (Philip Wong)'; 'pmayer 
(Patricia Mayer)'; 'Patricia Mayer"; 'tbe (Tom Eich)'; 'woody (Jay Tomlinson)' 
Re: Euterpe Module Review 


Tim B. Robinson wrote (on Thu Mar 30) : 

I assume you mean Friday? If so, 3pm is the scheduled Pandora 
meeting (that many of your invitees will be at.) 

Yes. Can we hold this review at 2 instead? 

OK, forget that suggestion. I see it's been rescheduled to Monday. 

Tim 
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From: vanthof (vant) 

Sent: Friday, March 31, 1995 12:21 AM 

To: 'mudge (john mudge)'; 'tbr (Tim B. Robinson)' 

Cc: 'vo (Tom Vo)'; 'albers (Daniel Albers)'; 'geert (Geert Rosseel)'; 'tomho (Tom Ho}'; 'michael 

(Chris Michael)'; 'hopper (Mark Hofmann)'; Vanthof (Dave Van't Hof)' 
Subject: Re: Corner devices 


john mudge writes: 
> 

>Dave , 

>I have modified the corner devices in the following manner and they 

>have 

been 

^checked in and I have run a final DRC. 
> 

>padbr: cbjtl has been exchanged for acbjtl 

> padextndl and padextnd2 have been added. 
> 

>padtr: cres2k2u has been exchanged for acbjt2 

> padextndl and padextnd2 have been added. 
> 

> Cells acbjtl, acbjt2, padextndl and padextnd2 have also been checked in 
to 

>proteus but not into the "pads" area which may be the more appropriate. 
In 

> talking to Tom Vo, he said there is no need to change any labels on the 
>layout as there are none to change. 


Johnny , 

Thanks, I've locked down the layouts and releasebom'd them. 

Tim, 

If you could do a getbom for the proteus snapshot for euterpe, then when that's done, 
I can start up another round of lvs/drc checks on euterpe. 

I'll start up the metals drc for mnemo and submit the lowers as well. 

Thanks , 
Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 
94089 

vanthof@microunity.com 1 408 734-8100 
"Don't blame me! I didn't vote for him" 
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From: 
Sent: 
To: 

Subject: 


Gary A. Hoffman [gary@Skipstone.com] 
Friday, March 31, 1995 12:27 AM 
'Curtis Abbott' 

Re: problems with ftp address 


Hi Curtis, 


I just thought we might chat about what all is going on in the 1394 market... not looking 
to hook ya for a consulting contract. Below is some information we have been sending out 
on our development kit. 

We will be an OEM supplier for TI component PCI & Cardbus adapters later this year and 
early next year respectively. We are continuing to work on our embedded application chip 
design, but we are not prepared to discuss that project in detail yet. 

cheers, g 

gary a hoffman 
Skipstone, CEO 
512.502.8464 office 
512.349.2139 fax 
gary . hof f man@skipstone . com 

On Fri, 3 Mar 1995, Curtis Abbott wrote: 


> "Gary A. Hoffman" wrote (on Thu Mar 2) : 

> 

> Hi Curtis, 
> 

> I was wondering if in addition to your getting the standard, if there 

> was anything else I might be able to fill in on 13 94? 

> 

> regards , g 
> 

> To be honest, I've been up to my neck in alligators and am still 

> reading through the standard. I'm definitely keeping your card in 

> case we decide to do something with 13 94, but I don't expect any 

> decisions like that in less than a couple months, when you say "fill 

> in on" I get the impression of something like consulting on what's 

> "really going on" with 13 94, which might be of interest at some point, 

> but when we spoke I got the impression you might be supplying more 

> material stuff (such as Verilog) . If you've got an email description 

> of your services and/or goods, that might be helpful. 
> 

> - Curtis 


Section 1: The IEEE 1394 TK-01 Developer Toolkit Section 2: About IEEE 1394 Section 3: 
The 1394 Trade Association Section 4: About Skipstone 

Please contact us and let us know how we can assist you in developing products for the 
IEEE 13 94 market. 

Daniel Moore 

Director of Communications 
dan . mooreOskipstone . com 

Skipstone, Inc. 

8920 Business Park Drive, Austin, Texas 78759 512-502-8464, fax 512-349-2139 
sales@skipstone . com 
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Note: We plan an address change in about a month but we will continue 
to check our current address after the move. If possible, please 
use our Internet address. We are sorry about this inconvenience 
but that is the price of growth 


Section 1: The 1394 TK-01 Developer Toolkit ============================================ 

The 1394 Developer Toolkit provides the hardware and software tools required to implement 
IEEE 1394 communication. And remember, it's designed by Skipstone, the IEEE 1394 serial 
bus experts. 

The 1394 Developer Toolkit contains: 
2 Skipstone PCI- 01 Interface Cards 
2 powerful software development tools: 
-- 13 94 Packet Injector 
13 94 Bus Analyzer 
-- 1394 Bus Manager software 
-- 13 94 Application API, DLL and VxD 
-- 1394 cable 
-- Complete documentation 

Also included are: 

-- 4 months of free technical support 
- - 6 months of free software upgrades 

Note: TK-01 software may not be redistributed. 


Technical Overview 


Skipstone PCI- 01 Interface Card 


an adapter card providing the interface between your computer's internal PCI bus and the 
external IEEE 13 94 bus. 

Packet Injector 


a software tool allowing you to insert IEEE 13 94 packets into the bus in either 
isochronous or asynchronous mode. The Packet Injector is used to simulate an IEEE 1394 
data source to provide a controlled test environment for evaluation of your application. 

1394 Bus Analyzer 


a software tool allowing you to monitor IEEE 1394 packets being carried on the bus. The 
Bus Analyzer provides you visibility into what type of data is being sent and its content. 
Filters are provided to selectively limit what type of data you want captured and this 
data may be displayed or saved in memory for future analysis. 

1394 Bus Manager 


the Bus Manager provides overall configuration control of the serial bus in the form of 
cycle master assignment, isochronous channel ID assignment and error recovery. 

API and DLL 


the Development API is the programming interface to which your application and the 
Developer Toolkit's tools are written. The API is a collection of programming calls 
providing high-level support over bus communication that frees the application from 
worrying about the details of programming the low level interface to the IEEE 13 94 bus. 
The Dynamic Link Library (DLL) is Windows ring 3 code implementing the API and providing 
an interface to the VxD (see next) . 

VxD 
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the virtual device driver for the Skipstone PCI- 01 Interface Card. 
Written specifically for this card, the VxD is updated to reflect new releases or 
different designs of the IEEE 13 94 interface thus making your application immune to 
hardware changes. 

Computer Requirements 


-- fully IBM- compatible computer 

486 processor at 66 mHz (faster if maximum bus rates are to be 
exercised) 
-- 1 PCI bus slot 
-- 8 -meg RAM (16 -meg preferred) 

5-meg hard disk space 
-- Windows 3.1 or Windows for Workgroups 3.11, MS-DOS 6.22 or higher 


TK-01 Developer Toolkit Release Schedule ======================================== 

The TK-01 Developer Toolkit is being released in stages to provide you the earliest 
possible access to IEEE 13 94 technology. Be assured that purchasers of the initial 
releases are provided free updates to later releases of the TK-01 toolkit. 

Release 1 - Now Shipping 


--2 Skipstone PCI- 01 Interface Cards 

-- IEEE 13 94 Application API and Virtual Device Driver for asynchronous 

data transfer 
-- File Transfer demo 
-- Source code example 
-- IEEE 1394 Cable 
-- Documentation 

-- 4 months of free technical support plus 6 months of free software 
upgrades 

Release 2 - planned April 30, 1995 


Release 1 plus 

-- IEEE 13 94 Application API, Virtual Device Driver and Resource Manager 

for isochronous data transfer with 13 94 limited bus management 
-- IEEE 13 94 Packet Injector and Bus Analyzer development tools 
-- Updated documentation 

Release 3 - date to be determined 


Release 2 plus 

-- IEEE 1394 Full Bus Management 
-- Updated documentation 


Additional 1H95 Skipstone products planned 
PCI-10 Interface Card 


a powerful upgrade of the current PCI- 01 Interface Card. The PCI-10 contains a 
microprocessor to enhance performance. 

TK-10 Developer's Toolkit 


the TK-01 Developer Toolkit upgraded for use with the PCI-10 Interface Card. 
TK-2 0 Embedded Application Toolkit 


an enhanced Developer Toolkit specifically tailored for embedded applications. 


Price List 
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Part # Product Name 


Price 


TK-01 IEEE 13 94 Developer Toolkit $7500 
--2 PCI -01 Interface Adapter Cards 
-- IEEE 13 94 Development Software 
-- IEEE 13 94 Cable 

Toolkit Documentation 
-- 4 months Technical Support 
-- 6 months Software Upgrades 

PCI- 01 Additional 13 94 /PCI Interface Adapter $ 4 95 
cards purchased with TK-01 Toolkit 

PCI- 01 13 94 /PCI Interface Adapter cards $ 6 95 

not purchased with TK-01 Toolkit 
(see Note 1) 

PCI -10 Advanced 13 94 /PCI Interface Adapter 
- not yet available (see Note 2) 


Note 1: Price of PCI-01 interface adapter cards purchased without 
the Toolkit may be applied against price of Toolkit if the 
Toolkit is later purchased. 

Note 2: PCI- 10 interface adapter card is available only to purchasers 
of the Toolkit. 

Note 3: There will be an additional $60 fee for overseas delivery. 


Make all payments to: 

Skipstone , Inc . 
c/o Sales 

8 92 0 Business Park Drive 
Austin, TX 78759 

Wire transfer is the fastest method of delivery and payment. 
Contact us for details. 


Section 2: About IEEE 1394 


The IEEE 13 94 high-speed serial bus promises to revolutionize the transport of digital 
data for computers and for professional and consumer electronics products. By providing an 
inexpensive non-proprietary high-speed method of interconnecting digital devices, a truly 
universal I/O connection has been created. Its scaleable architecture and flexible peer- 
to-peer topology makes IEEE 13 94 ideal for connecting devices ranging from printers and 
hard drives to digital audio and video hardware with real time processing requirements for 
on-time multimedia. 

IEEE 13 94 is a standard, plat form- independent solution. Its features represent an 
evolutionary improvement over current I/O interfaces and provides connectivity solutions 
for many markets. Legacy I/O bridges attach serial and parallel interfaces to 1394. ASCII 
SCSI-3 provides a migration path for parallel SCSI to move to IEEE 1394. 

IEEE 13 94 can interface with the higher layers of the new parallel port standard, IEEE 
1284. Although IEEE 1294' s 4 to 32 Mbps transfer rate is lower than that of 1394, 1284 
finds application in printer connectivity since it is backward compatible with the 
existing Centronics parallel port. 

IEEE 13 94 devices of differing transport rates may be interconnected, allowing backward 
compatibility with devices having slower transport rates. This feature allows 100 Mbps 
devices purchased today to operate properly in future bus configurations involving 200 and 


Exhibit C12 


Page 621 of 643 


400 Mbps devices. 

The IEEE 13 94 serial bus is: 

--a digital interface: there is no need to convert digital data into 

analog and tolerate a loss of data integrity 
-- physically small: the thin serial cable can replace larger and more 

expensive interfaces 
-- easy to use: there is no need for terminators, device IDs, or 

elaborate setup 

hot pluggable: users can add or remove 13 94 devices with the bus 
active, 

-- inexpensive: priced for consumer products 

-- scalable architecture: may mix 100, 200, and 40 0 Mbps devices on one 
bus 

-- flexible topology: support of daisy chaining and branching for true 

peer-to-peer communication 
-- fast: even multimedia data can be guaranteed its bandwidth for 

just- in- time delivery 

Broad markets for IEEE 1394 digital data transport include: 
- - computers 

-- audio, image, and video products for multimedia 
-- printer and scanner products for imaging 
-- hard disks, especially hard disk Raid arrays 
-- digital video camera, displays, and recorders 

IEEE 1394 is currently defined by ANSI draft standard P1394. The IEEE Standards subgroup 
concerned with 13 94 successfully closed its ballot on 13 94 in December 1994 with formal 
1394 approval anticipated in the second quarter of 1995. 


Section 3: The IEEE 1394 Trade Association =========================================== 

The IEEE 1394 Trade Association was formed in September 1994 to accelerate the market 
adoption of IEEE 1394. Of special importance are the technical working groups that focus 
on refining the IEEE 

13 94 specification. The Trade Association steering committee is currently composed of 
representatives from Adaptec, AMD, Apple, IBM, Lexmark, Microsoft, National Semiconductor, 
NCR, Philips, Seagate, Skips tone, Sony, TI, and Toshiba. 

If you are interested in joining the Trade Association, contact Gary Hoffman, our CEO and 
chairperson of the Trade Association. 

You may call 512-502-8464 or contact him directly at gary.hoffman@skipstone.com. 


Section 4 : About Skips tone 


Skipstone was established in 1994 to become the central supplier of technology and 
products for the IEEE 13 94 serial bus architecture. 

Skipstone is focused totally on IEEE 13 94 development and is committed to bringing IEEE 
1394 to a dominant position in the computing, communications and entertainment markets. 


The Fine Print 


-- Skipstone is a trademark of Skipstone, Inc. 
-- IBM is a trademark of the International Business Machines 
Corporation. 

-- MS-DOS, Windows and Windows for Workgroups are trademarks of 
the Microsoft Corporation. 
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From: pmayer (Patricia Mayer) 
Sent: Friday, March 31, 1995 12:39 AM 
To: 'tbr' 
Cc: 'pmayer' 

Subject: Re: Euterpe Module Review 

> From tbr Thu Mar 30 20:25:16 1995 

> To: dbulfer (David Bulfer), howard (Howard Cowles), pandora, 

> philip (Philip Wong), pmayer (Patricia Mayer), 

> pmayer@microunity.com (Patricia Mayer), tbe (Tom Eich), 

> woody (Jay Tomlinson) 

> Subject: Re: Euterpe Module Review 
> 

> Tim B. Robinson wrote (on Thu Mar 30): 

> 

> I assume you mean Friday? If so, 3pm is the scheduled Pandora 

> meeting (that many of your invitees will be at.) 

> 

> Yes. Can we hold this review at 2 instead? 

> 

> OK, forget that suggestion. I see it's been rescheduled to Monday. 

> 

>Tim 

> 

>Also : 

>FromtbrThu Mar 30 20:07:16 1995 

> 

>I'm sure there will be issues arising from looking at what we have 
>(I'm aware of a couple of things already), so we should not hold off 
>any longer. 

> 

>Tim 

> 
> 

I'm keeping a running list, I thought the power supply had been resolved 
after taliking to both Woody and David... Thank you for the reminder. 

I've checked the Engineering conference room and it is available tomorrow 
at 2:00. Let me know and this can be changed easily. We might think about 
having a review tomorrow 2:00 so everyone can think about it over the weekend. 
Then list the action items and schedule another review for say Tuesday? 
Even if the changes are mechanical... its worth a review. 

Has David discussed holding off on the manufacturing until we are closer 
on Euterpe? Might be a good idea in case we discover ales and cures even 
on the Hestia Main board. We can have it ready for manufacturing with 
gerber files and all, ready to go at a momunts notice. 

I think this is a good idea. 
-Pattie 
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From: tbr 

Sent: Friday, March 31, 1995 12:42 AM 

To: 'vanthof {vant)' 

Cc: 'albers (Daniel Albers)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'Chris Michael'; 

John mudge'; 'Tom Ho'; 'Dave Van't Hof ; 'Tom Vo' 

Subject: Re: Corner devices 

Follow Up Flag: Follow up 

Flag Status: Red 


vant wrote (on Thu Mar 30): 

john mudge writes: 

> 

>Dave, 

>I have modified the corner devices in the following manner and they have been 
>checked in and I have run a final DRC. 

> 

>padbr: cbjtl has been exchanged for acbjtl 

> padextndl and padextnd2 have been added. 

> 

>padtr: cres2k2u has been exchanged for acbjt2 

> padextndl and padextnd2 have been added. 

> 

>Cells acbjtl, acbjt2, padextndl and padextnd2 have also been checked in to 
>proteus but not into the "pads" area which may be the more appropriate. In 
>talking to Tom Vo, he said there is no need to change any labels on the 
>layout as there are none to change. 

> 

Johnny, 

Thanks, I've locked down the layouts and releasebom'd them. 
Tim, 

If you could do a getbom for the proteus snapshot for euterpe, then when 
that's done, I can start up another round of Ivs/drc checks on euterpe. 

I'll start up the metals drc for mnemo and submit the lowers as well. 

Geert has a euterpe build going, so I don't want to mess with it till 
he gives the OK. Also, this will pick up kurt's pin swap magic. 
Are we sure all the problems are solved with the topt dumps on that 
one? 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Friday, March 31, 1995 12:42 AM 

Vanthof (vant)' 

'albers (Daniel Albers)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'michael (Chris 
Michael)'; 'mudge (john mudge)'; 'torn ho (Tom Ho)'; 'vanthof (Dave Van't Hot)'; 'vo (Tom Vo)' 
Re: Corner devices 


vant wrote (on Thu Mar 30) : 

john mudge writes: 
> 

>Dave , 

>I have modified the corner devices in the following manner and they have been 

>checked in and I have run a final DRC. 

> 

>padbr: cbjtl has been exchanged for acbjtl 

> padextndl and padextnd2 have been added. 

> 

>padtr: cres2k2u has been exchanged for acbjt2 

> padextndl and padextnd2 have been added. 
> 

>Cells acbjtl, acbjt2, padextndl and padextnd2 have also been checked in to 
>proteus but not into the "pads" area which may be the more appropriate. In 
>talking to Tom Vo, he said there is no need to change any labels on the 
> layout as there are none to change. 


Thanks, I've locked down the layouts and releasebom'd them. 
Tim, 

If you could do a getbom for the proteus snapshot for euterpe, then when 
that's done, I can start up another round of lvs/drc checks on euterpe. 

I'll start up the metals drc for mnemo and submit the lowers as well. 

Geert has a euterpe build going, so I don't want to mess with it till he gives the OK. 
Also, this will pick up kurt ' s pin swap magic. 

Are we sure all the problems are solved with the topt dumps on that one? 


> 


Johnny , 


Tim 
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From: tbr 

Sent: Friday, March 31 , 1995 12:47 AM 

To: 'prnayer (Patricia Mayer)' 

Cc: 'prnayer 1 

Subject: Re: Euterpe Module Review 

Follow Up Flag: Follow up 

Flag Status: Red 


Patricia Mayer wrote (on Thu Mar 30): 

I'm keeping a running list, I thought the power supply had been resolved 
after taliking to both Woody and David... Thank you for the reminder. 

From: dbulfer (David Bulfer) 

To: tbr@microunity.com (Tim B. Robinson) 

Cc: woody (Jay Tomlinson) 

Subject: Re: Euterpe module power connector 

Date: Thu, 30 Mar 95 15:15:31 PST 

> 
> 

> It appears the 6 pin power connector on the Euterpe module 

> has 3 pins assigned to each of gnd and 3.3V. Since we need the option 

> of plugging a 5 V cronus module into the the same backplane slot 

> we need 5 V assigned on this connector even though it will not be 

> hooked up on this module. Can we reassign to 2 pins each on gnd, 

> 3.3V, and 5V? 
> 

>Tim 

> 

We are looking into it. Specifically, we are looking at 2 pins for 
common 3V/5V gnd, 2 pins for 5V and 2 pins for 3V. A single contact 
is rated for 30A, but that is not the same as working well at 30A. 
Vijay has been assigned the task of analyzing how well 2 pins will 
work. He has promised me that he will hav an answer today. 

David 

I've checked the Engineering conference room and it is available tomorrow 
at 2:00. Let me know and this can be changed easily. We might think about 
having a review tomorrow 2:00 so everyone can think about it over the weekend. 
Then list the action items and schedule another review for say Tuesday? 
Even if the changes are mechanical... its worth a review. 

Main thing is to keep ajhead of Howard. I'd rather people had time to 
look at the plots/schematics before the meeting, (btw, please put 
lisr on the cc, she will be doing for pandora what wayne's doing for 
hestia). The monday morning time is fine with me. 

Has David discussed holding off on the manufacturing until we are closer 
on Euterpe? Might be a good idea in case we discover ales and cures even 
on the Hestia Main board. We can have it ready for manufacturing with 
gerber files and all, ready to go at a momunts notice. 
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I have not discussed it with him, but it would make sense to hold off. 
We won't have Euterpe for a long time yet, and we may find 
changes we need to make as we complete the mechanicals and get to the 
backplane. 

I think this is a good idea. 

I will put this on the agenda for my Pandora meeting Friday and let 
you know what the outcome is. 

Tim 
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Subject: 


Sent: 
To: 

Cc: 


From: 


vanthof (vant) 

Friday, March 31, 1995 12:49 AM 
Tim B. Robinson' 

'aibers (Daniel Albers)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'michael (Chris 
Michael)'; 'mudge Qohn mudge)'; 'tomho (Tom Ho)'; 'vo (Tom Vo)' 
Re: Corner devices 


Tim B . Robinson writes : 
> 

>Geert has a euterpe build going, so I don't want to mess with it till 
>he gives the OK. Also, this will pick up kurt ' s pin swap magic. 
>Are we sure all the problems are solved with the topt dumps on that 
>one? 


Oh okay. No problem. I can still run stuff on mnemo to keep the machines busy. 

I've done a bit more testing and actually confirmed the change I made to topt was the 
correct one. I've not heard about any other core dumps from the new port properties. TVo 
has found a bug when he tried to force an instance to a power level where topt chose a 
non-buffered version instead of a buffered version which only resulted in a timing 
violation, no core dump. 
I'll fix that tomorrow. 


> 


>Tim 


> 


Thanks , 


Dave 


Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 
94089 

vanthof@microunity.com 1 408 734-8100 
"Don't blame me I I didn't vote for him" 
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From: pmayer (Patricia Mayer) 

Sent: Friday, March 31, 1995 1:27 AM 

To: 'tbr' 

Subject: Re: Euterpe Module Review 

> From tbr Thu Mar 30 21:47:05 1995 

> To: pmayer (Patricia Mayer) 

> Subject: Re: Euterpe Module Review 

> 
> 

> Main thing is to keep ajhead of Howard. I'd rather people had time to 

> look at the plots/schematics before the meeting. 

Fine, I'll distribute this Friday afternoon for review and send out a notice. 
>(btw, please put lisr on the cc... 
What does this mean? 
-Pattie 
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From: tbr 

Sent: Friday, March 31, 1995 1:35 PM 

To: 'solo (John Campbell)' 

Cc: 'lisar (Lisa Robinson)'; 'geerf; 'mudge Gohn mudge)'; 'vanthof (Dave Van't Hot)'; Tom Vo' 

Subject: comer test devices 


Follow Up Flag: Follow up 
Flag Status: Red 


John Campbell wrote (on Fri Mar 31): 

we are about to introduce a change to the pad corner test devices 
which will reflect a change at the topi eve 1. padtr will essentially 
go away as a schematic instantiation and padbr will lose one pin 
(bjtle_v) which will now be tied to vsse ( ie remove from the verilog 
etc.) 

how do we handle this change. 

it is now ready to checkin the schematics but it will break the 
top level if we do. 

Are we talking about mnemo or euterpe? 

We are planning another snapshot update this weekend to pick up some 
routing rule changes. We should co-ordinate with that. I assume 
these changes will require baseplate regeneration. 

Tim 
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From: 
Sent: 
To: 

Subject: 


tbr 


Friday, March 31, 1995 1:46 AM 
'pmayer (Patricia Mayer)' 
Re: Euterpe Module Review 


Follow Up Flag: Follow up 
Flag Status: Red 

Patricia Mayer wrote (on Thu Mar 30): 

>(btw, please put lisr on the cc... 

What does this mean? 
It means I'm half asleep! It's a typo. I meant 'lisar'. 
Tim 
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From: 
Sent: 
To: 

Subject: 


chip (Potatoe Chip) 

Friday, March 31 , 1995 2:31 AM 

'geert' 

output of euterpe/verilog/bsrc/io/.checkoutrc 


The output from euterpe/verilog/bsrc/io/ . checkoutrc is 520k, so it is not included in this 
mail message. instead, check the file 

/n/tmp/chiplog/geert . staypuf t . 8019 . euterpe-verilog-bsrc- io 

(which is accessible from all machines) . This file will disappear in about 5 days. 
By the way, the exit status returned by . checkoutrc was 0. 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 
Friday, March 31, 1995 9:01 AM 
'Geert Rosseel' 
Re: pim2pif problem 


Geert Rosseel writes: 

I cannot figure out why it says this : 

# pim2pif Version 0.2.50 Thu Mar 30 10:33:34 PST 1995 

# /n/ghidra/s3/geert/euterpe/tools/bin/pim2pif . ex 
gards/geert_euterpe- iter .pirn -eel -logFile gards/geert_euterpe- iter. pirn. warn -noHole -xoff 
\set 2 -yoffset 2 

FATAL: Couldn't create the .pif file 
: gards/geert_euterpe- iter .pirn. pif . 52 : for writing 

FATAL: Errors encountered in .pirn section 52 

FATAL: Errors occurred on some section (s) of the .pirn file 


This is in /n/ghidra/s3 /geert /euterpe/verilog/bsrc/gards 

The pirn file is geert_euterpe-iter .pint 

This means that fopenO returned an error code. Typically this means that there is no 
space left on the disk. But there seems to be room (unless pim2pif cleaned up a lot of 
stuff when it exited) . I'll poke around, but you could run it again and keep an eye on 
disk space with (df .) to see if it hits 100%. 


-mark 
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From: hopper (Mark Hofmann) 

Sent: Friday, March 31, 1995 10:31 AM 

To: 'hardheads' 

Subject: pre-5pm disturbance: new pim2pif installed 

A bug (too many open files) in pim2pif was causing the critical 
top-level Euterpe pif generation to fail. If you haven't gotten 
"couldn't create/write/read file ..." messages from pim2pif you probably 
haven't tickled this bug. A patched version has just been released. 

As usual, please let me know if something else has broken. 

-thanks, 
hopper 
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From: hopper (Mark Hofmann) 
Sent: Friday, March 31, 1995 10:35 AM 
To: 'tbr (Tim B. Robinson)' 
Cc: 'lisar (Lisa Robinson)' 
Subject: long running job on aphrodite? 


hi tim, 
I see: 

Seq# Target Directory Machine(pid) Who Stat 

1 4220 euterpe/verilog/bsrc/hc aphrodite(2 131) tbr 1 7: 32 

And aphrodite shows: 
aphrodite/hopper45psx j g chip 

chip 3363 0.0 0.0 840 0? IWN 23:11 0:03 (gmake) 

chip 4070 0.0 0.0144884 0? DN 23:21 4:10 /n/auspex/slO/chip/euterpe/tools/sl/gards/dir/gplace hc0-pass2 
chip 3362 0.0 0.0 80 0? IWN 23:11 0:00 /bin/sh -c 

chip 2131 0.0 0.0 548 0 ? IW 21:57 0:46 Processing euterpe/verilog/bsrc/hc (4220) 

chip 4067 0.0 0.0 104 0? IWN 23:21 0:00 /bin/csh /n/auspex/slO/chip/euterpe/tools/sl/bin/invoke gplace hc0-pass2 

-listing hc0-pass2.gplace.lis -cmdin hc0-pass2. gplace. nic -colorin hc0-pass2.gplace.mobi234 -inbat 1 

chip 2134 0.0 0.0 540 0 ? IW 21:58 0:00 Process parent of /u/chip/tools/lib/bomutils/process-chip (2134) 

chip 2237 0.0 0.0 24 0? IWN 21:58 0:00 /bin/sh ./.checkoutrc 

chip 2302 0.0 0.0 536 0? IWN 21:59 0:02 gmake GARDS_DISPLAY=clio:0.0 gards/hcO-iter 
chip 2301 0.0 0.0 80 0? IWN 21:59 0:00 (sh) 
chip 4066 0,0 0.0 80 0? IWN 23:21 0:00 /bin/sh -c 

chip 2259 0.0 0.0 348 0 ? IWN 21:58 0:00 gmake GARDS_DI SPL A Y=clio: 0.0 hcOgards 
hopper 5866 0.0 0.2 104 224 p5 S 15:32 0:00 egrep -i chip 

chip 2148 0.0 0.0 36 0 ? IW 21:58 0:00 /bin/sh /u/chip/tools/lib/bomutils/process- 
ch ip /u/chip/tools/lib/bomutils/chipQ/4220 

chip 2135 0.0 0.0 36 0 ? IW 21:58 0:00 /bin/sh /u/chip/tools/1 ib/bomutils/process- 
chip/u/chip/tools/lib/bomutils/chipQ/4220 

Did you intend to do this build on aphrodite? 

just wondering... 
-hopper 
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From: lisar (Lisa Robinson) 
Sent: Friday, March 31, 1995 12:19 PM 
To: 'gmo'; 'doi'; 'guarino'; 'jeffm' 
Subject: Plea for some kind of listing 

Is there any way that I can get a listing for nullTest - can I run it 
on terp and dump out the equivalent? 

Lisa R. 
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From: vo (Tom Vo) 

Sent: Friday, March 31 , 1 995 1 :04 PM 

To: 'John Campbell' 

Cc: 'tbr (Tim B. Robinson)'; 'mudge (john mudge)'; 'lisar (Lisa Robinson)'; 'Dave Van't Hof ; 'Geert 
Rosseel' 

Subject: Re: corner test devicesh 

John Campbell wrote .... 

> 

>we are about to introduce a change to the pad corner test devices 
>which will reflect a change at the toplevel. padtr will essentially 
>go away as a schematic instantiation and padbr will lose one pin 
>(bjtle_v) which will now be tied to vsse ( ie remove from the verilog 
>etc. ) 
> 

>how do we handle this change. 

> 

>it is now ready to checkin the schematics but it will break the 

>toplevel if we do. 

>.... 

>regards, 

>solo a.k.a. John Campbell x516 


I deleted padtr from the toplevel lvs netlist make and checked in 
a new euterpe/verilog/bsrc/Makefile . 

tvo 
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From: solo (John Campbell) 

Sent: Friday, March 31 , 1995 1 :23 PM 

To: Tom Vo' 

Cc: 'solo@microunity.com'; 'tbr (Tim B. Robinson)'; 'mudge (john mudge)'; 'Lisa Robinson'; 'Dave Van't 
Hof ; 'Geert Rosseel' 

Subject: Re: comer test devicesh 

as Tom Vo was saying 

..John Campbell wrote .... 
..> 

,.>we are about to introduce a change to the pad corner test devices 
..> which will reflect a change at the top level, padtr will essentially 
..>go away as a schematic instantiation and padbr will lose one pin 
..>(bjtle_v) which will now be tied to vsse ( ie remove from the verilog 
..>etc. ) 
..> 

..>how do we handle this change. 

..> 

..>it is now ready to checkin the schematics but it will break the 

..>toplevel if we do. 

..>.... 

..>regards, 

..>solo a.k.a. John Campbell x5 1 6 


.1 deleted padtr from the toplevel lvs netlist make and checked in 
.a new euterpe/verilog/bsrc/Makefile . 

.tvo 


padbr was checked in and released, new padbr has its emitter tied to 
vsse and the body pin removed. 


regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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From: vo (Tom Vo) 

Sent: Friday, March 31 , 1 995 1 :42 PM 

To: Tim B. Robinson' 

Cc: 'solo (John Campbell)'; 'lisar (Lisa Robinson)'; 'geert (Geert Rosseel)'; 'john mudge'; 'Dave Van't 
Hof 

Subject: Re: corner test devices 

Tim B. Robinson wrote .... 

> 
> 

>Are we talking about mnemo or euterpe? 

Both . We're using the same corner for both chips . 

> 

>We are planning another snapshot update this weekend to pick up some 
>routing rule changes. We should co-ordinate with that. I assume 
>these changes will require baseplate regeneration. 

> 

>Tim 

We should not have to regenerate the baseplate as long as the cell origin 
remains the same . The baseplate lower layers will be different though once 
that cell got updated in $(CHIPROOT)/proteus/compass/layouts . 

tvo 
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Subject: 


Sent: 

To: 

Cc: 


From: 


solo (John Campbell) 

Friday, March 31, 1995 2:02 PM 

Tom Vo' 

•tbr@microunity.com'; 'lisar (Lisa Robinson)'; 'geert (Geert Rossee!)'; 'mudge (john mudge)'; 
Vanthof (Dave Van't Hot)' 
Re: corner test devices 


as Tom Vo was saying 

. .Tim B. Robinson wrote .... 

. . >Are we talking about mnemo or euterpe? 

..Both . We're using the same corner for both chips . 

. . > 

. . >We are planning another snapshot update this weekend to pick up some ,.>routing rule 
changes. We should co-ordinate with that. I assume . . >these changes will require 
baseplate regeneration. 


..We should not have to regenerate the baseplate as long as the cell origin ..remains the 
same . The baseplate lower layers will be different though once ..that cell got updated 
in $ (CHIPROOT) /proteus /compass/ layouts 


i agree with torn. just update the spice_cn and . ly files and everything else should be 
automatic. torn has already removed the schematic instantiation from the makefile. 


. . > 


. . >Tim 


. . tvo 


regards , 
solo a.k.a 


EMail solo@microunity.com 
John Campbell phone 408 734-8100 fax 408 734-8136 
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From: wampler (Kurt Wampler) 

Sent: Friday, March 31 , 1995 2:40 PM 

To: 'tbr' 

Cc: 'geert'; 'hopper' 

Subject: Update snapshot proteus/misc? 

Hi, Tim - 

I would really like to have the pin permutation on XBOR & XCNAND gates 
available for this weekend's top-level route. It looks like the only missing 
piece that remains is to update proteus/misc/emerge.tab. In the event that 
we're unable to get a top-level getbom & build done in the proteus snapshot 
before the top-level route, would it be permissible to update that one file 
in the proteus snapshot? 

I checked with Dave Van't Hof; he has confirmed that his topt fix related to 
the pin properties is reliable, and the relevant changes to the GPLACE 
incantation are in place in the euterpe snapshot, so I think the stage is 
set if we can get that one file brought up to date. Is this acceptable? 

-Kurt 
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From: pmayer (Patricia Mayer) 

Sent: Friday, March 31 , 1 995 5:45 PM 

To: 'toe'; 'dbulfer'; 'woody'; 'howard'; 'philip'; 'tbr' 

Cc: 'albers'; 'pmayer 1 

Subject: Plots for Euterpe PCB Review 

Copies of the current layout state are being distribued for your review. 
The meeting is still scheduled for Monday 10:00 in the Engineering conference 
Room. There are still many edits required to complete the board. Here's the 
list so far: 

Netlist edits: 

New circuit for PLL pins. 

Add 5v to the Power Connector. 

Add ground net to connector tabs (flange). 

Verification: 

The vias for diferential pairs have been moved, (possible .5 max length 
difference) 

Do we need/want test points? 
Has logo been approved? 

Mechanical: 

>From tbe@microunity.com Thu Mar 30 16:08:52 1995 

> Just to clarify, I have only supplied outline criteria and that having to 

> do with the Euterpe and SDRAM areas. There are still features such as 

> slots and hole to be placed outside the trace and component areas, and I am 

> working on completing that design for early next week, but the layout we 

> review Monday won't yet have those features in it. Does anyone have a 

> problem with reviewing what we will have done by Monday (traces and 

> components and pcb outline)? 

Layout issues: 

Add ground plane around corner of tab. 

Clear tab of solder mask, 

Rename components - Back annotate. 

Drawing dimensions, detail for cutout 

Round up special notes for drawings, Fab and Assy 

Create Gerbers, drill, ncrouter 

♦♦Depending on the edits and changes listed above, Tuesday evening would be the 
earliest this board can be archived for manufacturing. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 
Friday, March 31, 1995 6:06 PM 
'vant' 

'geert (Geert Rosseel)'; 'wampler (Kurt Wampler)'; Vanthof (Dave Van't Hof)'; 'lisar (Lisa 
Robinson)'; 'vo (Tom Vo)'; 'tbr (Tim B. Robinson)' 
Re: euterpe Ivs still failed 


vant writes: 
Hi, 

The euterpe lvs came back and there is still a cross in phi_a and phi_b 
in the gtlb. The cell crclkintll . ly was last updated on the 27th in 
the snapshot and the lvs was started on the 2 8th and also referenced that 
layout so I'm confident that those edits were picked up. If anyone would 
like to look at the error file it's in: 


/u/ vanthof /compass /mobi/euterpe/tapeout/ euterpe . compare / euterpe . lvs 

I'll try to take a look at it in the morning. 

Well I'm confused. The edits look good. I don't understand how this layout can give the 
same result as the last run. Even if we did not identify the error, we surely changed 
something. Aaargh. . . . 


-hopper 
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